GDCC/HDC 3B-Bi-directional LDN messaging, Template Instructions #8775
Conversation
Updated messages to include relationship verb Sending to all superusers who can publish the dataset
(doesn't fix coar issue) - may not be needed (real titanium 1.2+ uses jakarata.json which we can't do yet on J2EE 8 afaik)
mod title -> sorg:name
|
Passing through again, haven't had a chance to dig into the docs (thanks!) but I noticed a couple API tests failing at https://jenkins.dataverse.org/job/IQSS-Dataverse-Develop-PR/job/PR-8775/19/testReport/ |
|
Issue found with templates: can add instructional text to template fields and that text is copied when copying the template but can no longer edit template metadata, the fields are not displayed to edit. Also, no release notes and no citation block change or instructions, "the DASH-NRS entry in the citation metadatablock" |
|
Not sure I understand. After adding template instructions, I can save, copy to create a new template, see the custom instructions, save, and come back to edit that copy and still see the custom instructions. |
|
@qqmyers I can test it again but reediting the template after saving is what seems to be the problem. No fields appear, only the save button. Copying works fine, adding/removing the instructions during the initial edit works fine. |
|
|
||
| List <MetadataBlock> viewMDB = new ArrayList<>(); | ||
| List <MetadataBlock> editMDB=this.getDataverse().getMetadataBlocks(true); | ||
| List <MetadataBlock> editMDB=this.getDataverse().getMetadataBlocks(false); |
There was a problem hiding this comment.
Note this line is a fix for a bug found in testing that appears to come from #8837. With true, this call only gets metadatablocks from the current collection and, if it isn't the metadatablockroot/inherits which blocks to use from its parent(s), then no blocks are returned. Using false (or getMetadataBlocks() which redirects to getMetadataBlocks(false)) the call recurses up through parents until it finds the one where the metadatablocks are defined.
Testing should check the cases from #8735 to make sure this doesn't revert anything. As far as I can tell, selecting a new block in a parent, or in the current collection and then editing an existing template does show the newly selected block as well.
|
|
||
| //The metadatablocks in this template include any from the Dataverse it is associated with | ||
| //plus any others where the template has a displayable field (i.e. from before a block was dropped in the dataverse/collection) | ||
| viewMDB.addAll(this.getDataverse().getMetadataBlocks(true)); |
There was a problem hiding this comment.
My guess is that this call is no longer needed. As is it gets no blocks unless the current one is the metadatablockroot and it is the loop below that adds the right blocks. Looking back at #8837 where this was added, there used to be one list of blocks for edit and view, which is why getting the available blocks was needed. Now that this variable is just for view, I don't think getting the possible blocks is needed. (I also don't think it hurts in that for view, only the blocks with defined fields appear anyway, so having extra blocks in viewMDB doesn't break anything.
|
Note, release notes are composite here: #8894 |
…ded by qqmyers, please check if the conflict has been resolved. As we do not have access to the conflict details, if the modification does not resolve the conflict, please follow up with the file name and line number of the conflict and we will follow up with the modification.
What this PR does / why we need it: This PR includes functionality created for the Harvard Data Commons project and includes:
Which issue(s) this PR closes:
Closes #7882
Special notes for your reviewer: Having just gone through the process to split HDC 3A work into multiple PRs, and messing things up at least once, I thought I would at least start by presenting this one as a ~coherent whole for discussion, and, if it should be broken apart, would like to get some guidance on how many parts and how best to do that.
At present, there are a couple minor additions that aren't technically part of this work:
Suggestions on how to test this: The HDC 3B group has a test protocol for the basic LDN message exchanges as well as a test server set up to run this in parallel with a test instance of DASH. At merge time, we could make sure the code there is updated from this branch (i.e. after more merges with develop), so that it can be run with DASH. It would also be possible to craft/send a json-ld message to the LDNInbox manually, and for the outgoing workflow, one could configure the LDN step and at least check the log to see the message contents, etc.
For the template instructions, it would be straightforward to create a template, click to add custom instructions, create a dataset using the template to see the custom instructions, clone a template to make sure the custom instructions are transferred to the template copy, etc.
Also note that the LDN messaging is intended to ultimately be compliant with the COAR Notify standard, but this doesn't yet exist in final form. For that reason, I think I'll document the LDN send/receive as 'experimental/likely to change' for now.
Also also note that the PR includes a custom copy of the latest titanium json-ld library. The latest version has moved to EE9 and changed all the package names. The copy here is a duplicate except for package names and would go away as soon as #8774 goes through. I originally upgraded trying to resolve an issue in parsing the LDN ~COAR message format but ultimately had to make other changes to get it to work, so it is possible that the update isn't strictly necessary. (If there's a desire to remove it, I'd want to go back and check that the older version doesn't have security issues - it's been quite a while since we last updated.)
Does this PR introduce a user interface change? If mockups are available, please link/include them here: There are several additions to the UI, most of which were reviewed by the UI design team as development proceeded. In particular, the user notification messages from receiving an LDN message, the DASH-NRS entry in the citation metadatablock, the placement/style of custom instructions in the edit dataset view have been looked at. The one piece of new functionality is the mechanism to edit instructions in a template. The edit option was placed just above the individual data fields in the same place that the resuls appear for metadata editing in the dataset.
Is there a release notes update needed for this change?: Yes - probably mentions of the LDN send/receive and the template instructions as two features.
Additional documentation: Lots of 3B documentation exists. I still need to document the LDN send/receive and the template instructions in the guides.