EPrints Technical Mailing List Archive
See the EPrints wiki for instructions on how to join this mailing list and related information.
Message: #08249
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
[EP-tech] Short workflow
- To: <eprints-tech@ecs.soton.ac.uk>
- Subject: [EP-tech] Short workflow
- From: <martin.braendle@uzh.ch>
- Date: Sun, 12 Jul 2020 10:12:23 +0200
Hi everyone,
we had the idea to offer a single-stage submission workflow after complaints of a VIP at our university that the current workflow requires too many clicks.
This short workflow would be activated after an import of an item from Crossref, PubMed, ORCID or another source (e.g. at the first revision of the item and if the source is known), and would only offer the missing required fields and the upload component. For many users (we have several hundred submitters adding more than 10'000 items annually), this would save hours of work.
However, after implementing such a single stage, we observed that some components have the following problems if merged into one stage with other components:
- the Subject component crashes the application after choosing a subject for adding (leading to a "Can't call method "get_state_params" on an undefined value at /service-app/apps/eprints/perl_lib/EPrints/Workflow.pm line 499.\n" error).
- the Upload component does not return feedback when uploading a document (it goes on infinitely). After interruption, however, the system indicates that the document had been uploaded and is there.
Definitely something is wrong with the workflow engine. In my opinion, components should be freely includable in whatever part of the stage.
Has anybody else tried to achieve something similar and had success?
Kind regards,
Martin
we had the idea to offer a single-stage submission workflow after complaints of a VIP at our university that the current workflow requires too many clicks.
This short workflow would be activated after an import of an item from Crossref, PubMed, ORCID or another source (e.g. at the first revision of the item and if the source is known), and would only offer the missing required fields and the upload component. For many users (we have several hundred submitters adding more than 10'000 items annually), this would save hours of work.
However, after implementing such a single stage, we observed that some components have the following problems if merged into one stage with other components:
- the Subject component crashes the application after choosing a subject for adding (leading to a "Can't call method "get_state_params" on an undefined value at /service-app/apps/eprints/perl_lib/EPrints/Workflow.pm line 499.\n" error).
- the Upload component does not return feedback when uploading a document (it goes on infinitely). After interruption, however, the system indicates that the document had been uploaded and is there.
Definitely something is wrong with the workflow engine. In my opinion, components should be freely includable in whatever part of the stage.
Has anybody else tried to achieve something similar and had success?
Kind regards,
Martin
- Follow-Ups:
- [EP-tech] Short workflow
- From: <martin.braendle@uzh.ch>
- [EP-tech] Short workflow
- References:
- [EP-tech] Short workflow
- From: <martin.braendle@uzh.ch>
- [EP-tech] Short workflow
- Prev by Date: Re: [EP-tech] use of uninitialized value in string eq during eprint->commit
- Next by Date: Re: [EP-tech] Short workflow
- Previous by thread: [EP-tech] EPrints/CRIS
- Next by thread: [EP-tech] DOI handling in orcid_support_advance
- Index(es):