• OJS 3.4.0-5
• Funding plugin installed from plugin gallery

[22-May-2024 00:24:22 Europe/Berlin] PHP Fatal error:  Uncaught Exception: Unrecognized DAO UserGroupDAO! in /html/ojs/lib/pkp/classes/db/DAORegistry.php:77
Stack trace:
#0 /html/ojs/plugins/generic/funding/controllers/grid/FunderGridHandler.inc.php(305): PKP\db\DAORegistry::getDAO('...')
#1 /html/ojs/plugins/generic/funding/controllers/grid/FunderGridHandler.inc.php(129): FunderGridHandler->canAdminister(Object(PKP\user\User))
#2 /html/ojs/lib/pkp/classes/core/PKPRouter.php(331): FunderGridHandler->initialize(Object(APP\core\Request), Array)
#3 /html/ojs/lib/pkp/classes/core/PKPComponentRouter.php(291): PKP\core\PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(APP\core\Request), Array)
#4 /html/ojs/lib/pkp/classes/core/Dispatcher.php(165): PKP\core\PKPComponentRouter->route(Object(APP\core\Request))
#5 /html/ojs/lib/pkp/classes/core/PKPApplication.php(388): PKP\core\Dispatcher->dispatch(Object(APP\core\Request))
#6 /html/ojs/index.php(21): PKP\core\PKPApplication->execute()
#7 {main}
  thrown in /html/ojs/lib/pkp/classes/db/DAORegistry.php on line 77

We use OMP 3.3.0.17 and the Funding Plugin in version 2.1.4.2. As soon as the plugin is activated, it is no longer possible to open a publication on the website. The following error message appears in the Apache log:

PHP Fatal error: Uncaught Error: Call to a member function getId() on null in /srv/www/htdocs/omp/plugins/generic/funding/FundingPlugin.inc.php:182 Stack trace: #0 /srv/www/htdocs/omp/lib/pkp/classes/plugins/HookRegistry.inc.php(107): FundingPlugin->addSubmissionDisplay() #1 /srv/www/htdocs/omp/lib/pkp/classes/template/PKPTemplateManager.inc.php(1577): HookRegistry::call() #2 /srv/www/htdocs/omp/cache/t_compile/4838d1eb315c43da6fc0c608df23899f50941f69^1a43403fc96a795020edfbc1cc6004aa859621c9_0.app.frontendobjectsmonograph_full.tpl.php(796): PKPTemplateManager->smartyCallHook() #3 /srv/www/htdocs/omp/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_663a1a5f6f5c42_95435398() #4 /srv/www/htdocs/omp/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode() #5 /srv/www/htdocs/omp/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render() #6 /srv/www/htdocs/omp/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(386): Smarty_Internal_Template->render() #7 /srv/www/htdocs/omp/cache/t_compile/4838d1eb315c43da6fc0c608df23899f50941f69^fad89cb5a0797f0c714bbc0b3dbced067d74491e_0.app.frontendpagesbook.tpl.php(31): Smarty_Internal_Template->_subTemplateRender() #8 /srv/www/htdocs/omp/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_663a1a5f61ee79_79407083() #9 /srv/www/htdocs/omp/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode() #10 /srv/www/htdocs/omp/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render() #11 /srv/www/htdocs/omp/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(238): Smarty_Internal_Template->render() #12 /srv/www/htdocs/omp/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(134): Smarty_Internal_TemplateBase->_execute() #13 /srv/www/htdocs/omp/lib/pkp/classes/template/PKPTemplateManager.inc.php(1246): Smarty_Internal_TemplateBase->display() #14 /srv/www/htdocs/omp/pages/catalog/CatalogBookHandler.inc.php(205): PKPTemplateManager->display() #15 /srv/www/htdocs/omp/lib/pkp/classes/core/PKPRouter.inc.php(397): CatalogBookHandler->book() #16 /srv/www/htdocs/omp/lib/pkp/classes/core/PKPPageRouter.inc.php(246): PKPRouter->_authorizeInitializeAndCallRequest() #17 /srv/www/htdocs/omp/lib/pkp/classes/core/Dispatcher.inc.php(144): PKPPageRouter->route() #18 /srv/www/htdocs/omp/lib/pkp/classes/core/PKPApplication.inc.php(360): Dispatcher->dispatch() #19 /srv/www/htdocs/omp/index.php(64): PKPApplication->execute() #20 {main} thrown in /srv/www/htdocs/omp/plugins/generic/funding/FundingPlugin.inc.php on line 182

The problem is that the key 'monograph' does not exist in the array of template variables ($templateMgr->get_template_vars('monograph')). In my opinion, the key you are looking for in OMP should be 'publishedSubmission'. I'm not sure, but pkp/omp#686 could be related to this.

Hi,

Thank you for the contributions you have done @bozana

I changed the plugin version to 2.1, edited the version.xml file and readme.

I think that it would make sense if the readme would state that I have authored the original 2.0 version with the funding from OpenAIRE. Then we could add all your contributions to the 2.1 version and say that the contributions for 2.1 were made by you/PKP. If I forgot something from the changes you have made for 2.1, then please add them to the readme file!

• DC
• marc
• other?

Hi @bozana

While thinking about the release, one more thing comes to mind. Should we save the whole URI as the identifier OR just the prefix/suffix part. I noticed that the CrossRef API is still returning the old dx.doi.org URI and maybe the protocoll could change later as well?

Of course these could be changed with a single line of sql later on...

In some cases a funder may be missing from the funder registry.

At the moment the plugin will let you to save a new name, but the ID for the funder will of course be missing.

We need to find out what CrossRef thinks about this. Do they

1. Only want data with ID's, meaning that we should a) only allow funder names from the registry or b) only send funder data that has an ID to CrossRef
2. Allow funder names without ID's, and if so, how should this show in the XML

They do not give any clear answe to these questions here: https://www.crossref.org/services/content-registration/funding-data/

Hi @bozana

I talked about the plugin with folks from Crossref and they seemed to be mainly pleased with the end result. The one change we need however is the ability to enter a more detailed funder name, I mean a sub-organization.

How it would work is that you first search for a funder. After selecting the funder, the plugin should fetch the names and DOIs of the sub-organizations of the selected funder and let you to do a more detailed selection among those names. Basically the easiest solution would be a pull down menu that appears under the selected funder name if there are other suborganizations available.

I also think that we should rename the plugin to "funding plugin", because there is no fundRef anymore and the same data is probably used in OpenAire etc. as well.

This issue is based on the current OpenAIRE guidelines, but the guidelines are likely to change soon pkp/pkp-lib#828 (comment)

After changing the database model according to this issue #16 we can save funding data that will support also OpenAIRE and Datacite specifitions which have a bit more data.

API for accessing OpenAIRE project data

http://api.openaire.eu/search/projects, example http://api.openaire.eu/search/projects?grantID=302009
http://api.openaire.eu/#sec_http-projects
https://wiki.surfnet.nl/display/standards/info-eu-repo#info-eu-repo-GrantAgreementIdentifiers

Note! Adding an OpenAIRE funding data could include a more controlled form, where for example the Funder and FundingProgramme would be selected with radio buttons.

We could still use the OpenAIRE funding data for CrossRef exports as well. Just have to make sure what data in the OpenAIRE model should be used.

For the latest and best version of the OpenAIRE plugin, see https://github.com/4Science/ojs/tree/ingv-fp7-post-grant/plugins/generic/openAIRE

* Only two options: European Commission (EC) or Wellcome Trust (WT). For OAI the acronyms are used.
** Not sure if the projectID is/can be the exact same thing?
*** only two options: FP7 and H2020
 
Sources:
https://support.crossref.org/hc/en-us/articles/214360746-Funding-data-overview
https://guidelines.openaire.eu/en/latest/literature/field_projectid.html
https://schema.datacite.org/meta/kernel-4.0/

Should be as simple as adding something like pkp/pkp-lib@992ca67 to the grid handler.

s. #7 (comment)

the editing of the funding data should only be possible:

• for authors before the final submission
• for sub_editors and assistants if they are assigned to the submission
• for managers always

When saving a suborganization, the name of the actual organization is not saved anywhere. With the DOI you can of course query the crossref API and find out what the organization is, but for visual purposes we should consider saving the name of the organization so that we can show it on the article page and maybe also elsewhere.

Suggested format when saving:
Organization Name: Suborganization Name

What do you think @bozana?

When configuring DOIs with Crossref in OJS 3.4.0-5 and enabling the Funding Plugin desposition fails with the following error:

{
    "message": "Unrecognized DAO SubmissionDAO!",
    "code": 0,
    "file": "\/public_html\/lib\/pkp\/classes\/db\/DAORegistry.php",
    "line": 77,
    "trace": [
        {
            "file": "\/public_html\/plugins\/generic\/funding\/FundingPlugin.inc.php",
            "line": 303,
            "function": "getDAO",
            "class": "PKP\\db\\DAORegistry",
            "type": "::",
            "args": [
                "SubmissionDAO"
            ]
        },
        {
            "function": "addCrossrefElement",
            "class": "FundingPlugin",
            "type": "->",
            "args": [
                "articlecrossrefxmlfilter::execute",
                [
                    []
                ]
            ]
        },

When disabeling the Funding Plugin deposition works as expected.

The metadata form outputs an error for the author if the plugin is enabled.

Just a reminder to @defstat for the pr regarding the port to OMP...

After changing the database model according to this issue #16 we can save different kinds of funding data.

https://schema.datacite.org/meta/kernel-4.0/example/datacite-example-fundingReference-v.4.0.xml

<fundingReferences>
<fundingReference>
<funderName>European Commission</funderName>
<funderIdentifier funderIdentifierType="Crossref Funder ID">http://doi.org/10.13039/501100000780</funderIdentifier>
<awardNumber awardURI="http://cordis.europa.eu/project/rcn/100180_en.html">282625</awardNumber>
<awardTitle>MOTivational strength of ecosystem services and alternative ways to express the value of BIOdiversity</awardTitle>
</fundingReference>
</fundingReferences>

* Only two options: European Commission (EC) or Wellcome Trust (WT)? For OAI the acronyms are used.
** Not sure if the projectID is/can be the exact same thing?
*** only two options: FP7 and H2020?

Sources:
https://support.crossref.org/hc/en-us/articles/214360746-Funding-data-overview
https://guidelines.openaire.eu/en/latest/literature/field_projectid.html
https://schema.datacite.org/meta/kernel-4.0/

A PKP hosting client using OJS 3.1 is having difficulty adding a new funder to the submission metadata. When you try to enter the funder name in the Funder Name and Identification field, no names come up, you can only enter the funder DOI. An endlessly scrolling search wheel appears. And then if you enter the funder DOI, the DOI displays in the submission metadata instead of the name of the funder.

The database should be changed to a four table combination. This change will make the plugin more combatible with later modifications like OpenAIRE and Datacite support even if we do not support those with the first release.

This may need more consideration, but:

funder

funder_id [int]
funder_identifier [string, doi or something else]*
submission_id
context_id

funder_settings

funder_id
locale
setting_name
setting_value
setting_type

funder_award

funder_award_id [int]
funder_id [int]
funder_award_number [string]

funder_award_settings**

funder_award_id
locale
setting_name
setting_value
setting_type

* this is probably not needed. We just need some checks for the OpenAIRE data for showing it in OAI, basically when fundingProgramme exists, we are dealing with OpenAIRE data. For Datacite/Crossref combatibility, we need to make sure if Datacite is ok with receiving
** or add awardTitle and awardURI fields to funder_award table, but this would prevent localisation etc. I any case adding the awardTitle and awardURI option to the form will involve chancing the way that data is entered because we need to pair up the awardNumber and the awardTitle.

Example of saved CrossRef funding data:
funder: '125', 'crossref', 'http://dx.doi.org/10.13039/501100000780'
funder_settings: '125', 'en_US', 'funderName', 'European Commission', 'string'
funder_award: '241', '125', '456566'

Example of saved OpenAIRE funding data:
funder: '126', 'openaire', 'http://dx.doi.org/10.13039/501100000780'
funder_settings: '126', 'en_US', 'funderName', 'European Commission', 'string'
funder_settings: '126', 'en_US', 'fundingProgramme', 'FP7', 'string'
funder_award: '254', '126', 'DE53522'
funder_award_settings: '254', 'en_US', 'awardTitle', 'My fabulous research project', 'string'

Example of saved Datacite funding data:
funder: '127', 'datacite', 'http://dx.doi.org/10.13039/501100000780'
funder_settings: '127', 'en_US', 'funderName', 'European Commission', 'string'
funder_award: '322', '127', 'DE53522'
funder_award_settings: '322', 'en_US', 'awardTitle', 'My fabulous research project', 'string'
funder_award_settings: '322', '', 'awardURI', 'http://www.awardinfo.com/is/here', 'string'

* Only two options: European Commission (EC) or Wellcome Trust (WT)? For OAI the acronyms are used.
** Not sure if the projectID is/can be the exact same thing?
*** only two options: FP7 and H2020?

Sources:
https://support.crossref.org/hc/en-us/articles/214360746-Funding-data-overview
https://guidelines.openaire.eu/en/latest/literature/field_projectid.html
https://schema.datacite.org/meta/kernel-4.0/