Closed peetucket closed 6 years ago
Remove:
https://github.com/sul-dlss/argo/blob/master/app/helpers/registration_helper.rb#L48-L52 https://github.com/sul-dlss/argo/blob/master/app/assets/javascripts/registration/grid.js.erb#L473-L482 https://github.com/sul-dlss/argo/blob/master/app/assets/javascripts/registration/register.js.erb#L50-L53 https://github.com/sul-dlss/argo/blob/master/lib/constants.rb#L8-L12 https://github.com/sul-dlss/argo/blob/master/app/views/items/register.html.erb#L18 https://github.com/sul-dlss/argo/blob/master/spec/features/item_registration_spec.rb#L25-L38
Edit this line to remove reference to "external_workflow_id":
https://github.com/sul-dlss/argo/blob/master/app/assets/javascripts/registration/grid.js.erb#L431
This feature was at the request of the digitization team, to inform Goobi via the tag which flavor of goobi workflow should be used. Is the requirement gone, i.e. only one flavor of goobi workflow is in use and can be assumed?
I think what changed is that they now have a different Goobi workflow per project, which would mean having to constantly update the drop-down menu of possible Goobi workflows (currently hardcoded into Argo) for each new project.
Since this drop-down menu was simply triggering the creation of a tag, by removing it they are back to just adding the tag manually with the appropriate goobi workflow name when registering.
Other options considered were to turn that drop-down into a free form text box where you could type in any goobi workflow name you wanted, but is only marginally better than manual tag entry (which is what this PR reverts to).
The best possible option (but the most work), would be to have some API call from goobi that could be called from argo to dynamically populate that drop-down with only the workflows defined in goobi (assuming that Goobi API call even exists). This would be the most work.
If there’s a different goobi WF per project then perhaps they could use the project name they enter, but I suspect that would serve for making a human connection and they want/need a more formal goobi workflow name for automation. A separate input field would guarantee well-formedness better, or managing goobi choice lists in the APO might be a nice solution for later (it’s the sort of thing governance should provide). But if they are willing to procedurally just enter it as a tag for now, it works for me.
On Jan 18, 2018, at 1:42 PM, Peter Mangiafico notifications@github.com wrote:
I think what changed is that they now have a different Goobi workflow per project, which would mean having to constantly update the drop-down menu of possible Goobi workflows (currently hardcoded into Argo) for each new project.
Since this drop-down menu was simply triggering the creation of a tag, by removing it they are back to just adding the tag manually with the appropriate goobi workflow name when registering.
Other options considered were to turn that drop-down into a free form text box where you could type in any goobi workflow name you wanted, but is only marginally better than manual tag entry (which is what this PR reverts to).
The best possible option (but the most work), would be to have some API call from goobi that could be called from argo to dynamically populate that drop-down with only the workflows defined in goobi (assuming that Goobi API call even exists). This would be the most work.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Currently, in item registration, when you select "goobiWF" as the initial workflow, we show a drop-down menu called "Goobi Workflow" with options that are hardcoded. Having hard-coded options is not going to work, and it is better to just remove this feature completely, along with what it triggered, which is the creation of a tag at registration.