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 8578 - Affix license to submissions; disentangle copyright from license in setup
Affix license to submissions; disentangle copyright from license in setup
Product: OJS
Classification: Unclassified
Component: General
All All
: P3 normal
Assigned To: Alec Smecher
: 3590 6423 7916 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2014-02-24 16:45 PST by Alec Smecher
Modified: 2014-08-18 14:05 PDT (History)
4 users (show)

See Also:
Version Reported In:
Also Affects:

Patch against OJS 2.4.3 (173.59 KB, patch)
2014-02-24 16:46 PST, Alec Smecher
Details | Diff
Patch against OJS 2.4.3 (143.33 KB, patch)
2014-03-05 13:57 PST, Alec Smecher
Details | Diff
Updated patch with wording tweaks and metadata exposure improvement (146.49 KB, patch)
2014-03-06 15:29 PST, Alec Smecher
Details | Diff
Updated patch with wording tweaks and metadata exposure improvement (146.13 KB, patch)
2014-03-06 15:37 PST, Alec Smecher
Details | Diff
Patch against OJS 2.4.3 (153.52 KB, patch)
2014-03-20 16:40 PDT, Alec Smecher
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alec Smecher 2014-02-24 16:45:40 PST
Affix license to submissions; disentangle copyright from license in setup
Comment 1 Alec Smecher 2014-02-24 16:46:03 PST
Created attachment 3986 [details]
Patch against OJS 2.4.3
Comment 2 Alec Smecher 2014-02-24 16:46:28 PST
The patch has NOT been committed to git yet -- pending a decision on whether to include this in 2.4.4, as it requires translation updates.
Comment 3 Alec Smecher 2014-03-05 13:57:57 PST
Created attachment 3990 [details]
Patch against OJS 2.4.3

Updated patch -- this one properly covers copyright statements.
Comment 4 Alec Smecher 2014-03-06 15:29:15 PST
Created attachment 3994 [details]
Updated patch with wording tweaks and metadata exposure improvement
Comment 5 Alec Smecher 2014-03-06 15:37:03 PST
Created attachment 3995 [details]
Updated patch with wording tweaks and metadata exposure improvement

(Removed patch-perplexing DuraSpace reference)
Comment 6 Alec Smecher 2014-03-10 14:42:11 PDT
- Make license URL monolingual
- Make the license URL a dropdown (CC-attrib, cc-noncommercial, other URL)
- Take out the license text field -- use CC if selected in dropdown, otherwise they can use the footer field.
Comment 7 Alec Smecher 2014-03-20 16:40:17 PDT
Created attachment 4004 [details]
Patch against OJS 2.4.3

Take 3: Remove license free-form field; provide CC examples; make URL non-localized; update import/export, front-end, and OAI formats
Comment 8 Alec Smecher 2014-03-21 11:30:45 PDT
Needs porting to OJS 3.0b next.
Comment 9 Alec Smecher 2014-03-21 11:32:02 PDT
Committed license/copyright changes
Comment 10 Clinton Graham 2014-06-24 13:23:02 PDT
In an upgrade to 2.4 from a version without Article-level licensing information, the copyright year (article_settings.setting_name = 'copyrightYear') is defaulting to the current year.  This is generating bad data for each article in an upgraded journal.

Steps to Reproduce:
Upgrade a journal with a version prior to https://github.com/pkp/ojs/commit/44198ed444730014e9af1deba9792c059575d33c to a version after https://github.com/pkp/ojs/commit/44198ed444730014e9af1deba9792c059575d33c .

Expected result:
The article's copyright year metadata will be populated with published date or submission date of the article.

Actual result:
The article's copyright year metadata is set to date('Y').  c.f. classes/article/Article.inc.php at _getLicenseFieldValue()
Comment 11 Alec Smecher 2014-06-24 14:51:12 PDT
Clinton, agreed that automatically attaching the current year as a default is a bad idea. That's my oversight in the data migration process.

However, I'm not sure automatically assuming the publication date is a good idea either.

What about a solution where already-published content doesn't get any year attached by default, so that existing dates need to be set manually in the metadata form (or via DB query where that's too costly)?
Comment 12 Alec Smecher 2014-06-25 08:48:23 PDT
*** Bug 7916 has been marked as a duplicate of this bug. ***
Comment 13 Clinton Graham 2014-06-26 10:29:59 PDT
Alec, I checked with our support folks, and we think manual assignment would generate far too much unnecessary work for large back runs.

I didn't take you to mean that leaving the copyright year unset for back issues would be a permanent solution.  I'm not aware of a better scripted source for the copyright date than the publication date.

Recognizing that the publication date is not a perfect source, do you have particular concerns of using it as the 'best available' source?
Comment 14 Clinton Graham 2014-07-01 07:18:07 PDT
I think this also duplicates http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=6423 (but I don't have the permissions to edit that above).
Comment 15 Clinton Graham 2014-07-01 12:07:34 PDT
This _getLicenseFieldValue() function also seems to suffer a bug where if a non-locale specific value is unset (line 195+), the logic "falls through" to reset all of the fields to the journal defaults (line 219+).

For example, in the Article's "Edit Metadata" screen, blanking the license url or year will reset all fields to the default in the database on the next access to the "Edit Metadata" screen.
Comment 16 Clinton Graham 2014-07-02 08:56:35 PDT

I think the first step to stop the population of bad data in the article level copyright metadata is to turn the defaults for the $preview parameters in these new functions to true rather than false.

Then, we can create an administrative function (automatically called in the upgrade process?) which calls _getLicenseFieldValue() for each article with a $preview of "false".

Comment 17 Alec Smecher 2014-07-02 16:20:08 PDT
*** Bug 6423 has been marked as a duplicate of this bug. ***
Comment 18 Alec Smecher 2014-07-02 16:23:30 PDT
Clinton, re: comment #15, are you seeing this in a situation that's not resulting from an upgrade where the previous install had no permissions data attached?

I'm currently considering the following...

When new content is published, the current "affix if there's nothing attached" code should serve. Specific exceptions (e.g. "expedited submission process" for old content) can be corrected by editing the submission metadata.

As far as I can see the problem is restricted to content that has gone through an upgrade. Once the JM configures the license information, articles will begin attaching permission information with potentially the wrong year.

I think the publication date would be a better assumption -- though still not perfect -- but in order for this to be effective, we'd have to ensure that other data not being set, such as the copyright holder, would not result in the newly-affixed year from being removed (per comment #15) after upgrade.

Does that capture it?
Comment 19 Clinton Graham 2014-07-03 05:59:12 PDT
Yes, the "affix copyright info if nothing is attached" should serve in the publication process.

I find it interesting, though, that for already published content, the _getLicenseFieldValue() is being called when browsing the article's metadata (and thus writing new metadata).  Surely browsing should not modify the data, hence another reason to default the $preview to true.

If I'm understanding the flow correctly, the issue with comment 15 is reproducible with new data as well as old:
1) Take a newly published article.
2) Customize the copyright metadata.
3) Browse to confirm changes.
4) Edit the customized metadata, removing the copyright year or license URL.
5) The next call to _getLicenseFieldValue() via editing or browsing(!) will reset the metadata to defaults.
Comment 20 Alec Smecher 2014-07-08 12:31:13 PDT
See http://pkp.sfu.ca/support/forum/viewtopic.php?f=8&t=12509&p=47877#p47877 for some SQL queries to set the permissions information.
Comment 21 Alec Smecher 2014-07-31 16:48:58 PDT
Filed bug #8859 to handle comment #10 onwards.
Comment 22 Alec Smecher 2014-07-31 17:36:41 PDT
Clinton (and others), I've attached a patch to bug #8859 that should address the upgrade data problem. Please test it if you can -- feedback is welcome. Once testing is done, this will be included with OJS 2.4.5.
Comment 23 Alec Smecher 2014-08-18 14:05:14 PDT
*** Bug 3590 has been marked as a duplicate of this bug. ***