We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 6423 - Updating copyright text should not update text by default for previously-published content
Updating copyright text should not update text by default for previously-publ...
Status: RESOLVED DUPLICATE of bug 8578
Product: OJS
Classification: Unclassified
Component: Submissions and Publishing
All All
: P3 normal
Assigned To: PKP Support
Depends on:
  Show dependency treegraph
Reported: 2011-02-17 14:46 PST by James MacGregor
Modified: 2014-07-02 16:20 PDT (History)
5 users (show)

See Also:
Version Reported In:
Also Affects: OCS 2.3.4, OMP 0.9, OMP 1.0


Note You need to log in before you can comment on or make changes to this bug.
Description James MacGregor 2011-02-17 14:46:23 PST
(Courtesy of http://pkp.sfu.ca/support/forum/viewtopic.php?f=9&t=7172&p=27720#p27720.)

Currently, the copyright info for a journal is monolithic: if it's changed, it is changed across the board. This is a problem as the copyright notice appears in each published article item's metadata, even though the author may have agreed to a previous form of the copyright statement. Iterations of the copyright statement should be stored within OJS, and the iteration of the statement that was displayed when the article was submitted should be tied to the article and displayed in its submission metadata, etc. 

This may get problematic wrt treating imported back issues. I would suggest that the system should display a copyright statement if one existed for the date_published value; and none otherwise.
Comment 1 Ramon Fonseca 2011-02-18 04:05:07 PST
In other, kind of related request:

- you could have specific submission checklists for every section. For example, the rules may be very strict for the Articles section, but not for the Technical Reports or Book and Media Review.
Allow the JM to "copy" the checklist for all sections, as well as editing them individually.

- Please publish with the issue specific journal metadata, such as editorial team, issue reviewers (those who worked on the articles published in the issue), about items, and whatever else identifies the journal. Journal configuration also changes across issues, and all the historical data gets lost, making it impossible to evaluate and study a journals evolution.
Comment 2 Mike Kamermans 2011-06-09 14:44:31 PDT
This is a great idea, but the way copyright is currently stored makes it -from what I can tell- impossible to implement without moving copyright (and other notices like them) to a new table of their own.

Copyright is currently stored as essentially a key/value pair in the "journal_settings" table, without a unique identifier to disambiguate between multiple copyrightNotice rows. A current database entry is (for instance)

  journal_settings(1, 'en_US', 'copyrightNotice', 'This is the current copyright notice text', 'string')

This uses the combination {journal_id,locale,setting_name} as identifier, so even if we added administrative key/value pairs to indicate which copyrightNotice row was effective as of when, we wouldn't be able to actually point at specific copyrightNotice records.

From whatI can see, the only way to really enable this functionality would be to create a new table of a form similar to:

journal_notices (
  'journal_id' pointing to the relevant journal
  'locale' pointing to the relevant locale,
  'notice_name' being at the very least 'copyrightNotice', but could conceivably also contain other notices,
  'notice_value' containing the notice text,
  'notice_version' being an incremental counter to track revisions (tied to the locale),
  'effective_since' the datetime the notice revision was entered into the database

I've included notice_version here, but this field can also be kept implicit based on the {locale,effective_since} pair; it depends a little on whether we can foresee a need for having it explicitly available later on.

This does feel like it will have a reasonably large impact (the db schema would need modification, copyright template handlers will need to query an additional table, etc.) so this might need some more discussion.
Comment 3 Alec Smecher 2012-09-21 14:22:09 PDT
CCing Bozana, since she was interested in this.
Comment 4 Alec Smecher 2014-07-02 16:20:08 PDT

*** This bug has been marked as a duplicate of bug 8578 ***