As a superuser, I want to make metadata updates without changing dataset version #4760
Comments
pdurbin
changed the title
|
Thanks @adam3smith. I ran this by @mercecrosas and she's OK with it. As far as implementation, I'm thinking API only and no front end. Do you (or anyone else out there) have any thoughts on this approach? |
|
Thanks for checking. API-only works for us |
|
@scolapasta - I have this one as ready to be estimated and I'd like to get your thoughts on the architecture here. Would this be a separate API endpoint or would the "no version update" be something that's passed as part of a request to a current endpoint? Or something completely different? I feel like the latter would be more scalable, but I'm not familiar enough with this. Thanks! |
|
@djbrooke trying to follow the status changes on this ticket -- could you briefly say what the status is here? |
|
@adam3smith hi, @djbrooke is on vacation but by looking at https://waffle.io/IQSS/dataverse I can see that it's under the "Ready" column (recently renamed from "Backlog" so we should also update the GitHub label, changing it from "Backlog" to "Ready") but it hasn't yet been estimated. That is to say, it hasn't yet been given a "size" in Waffle. We give issues a size/estimate during sprint planning and backlog grooming meetings on Wednesday afternoons. I'm not sure when we'll estimate this one. If you think it would be helpful for us to write up a little more on our process in the dev guide or CONTRIBUTING.md or elsewhere, please let us know! A separate issue would be best. Thanks! |
|
Thanks -- that's actually how I (think I) understood the process, but then I would have expected the "ready for estimation" label to stay on the issue until it was estimated? Or did you just retire that label? |
|
The "ready for estimation" label is new and still in use. The pattern so far has been to add "ready for estimation" and then assign it to someone who who explain the issue during sprint planning or backlog grooming so that we can estimate the effort (size in Waffle). |
pdurbin
added
Status: Backlog
Feature: Publishing & Versions
and removed
Status: Backlog
labels
|
@pdurbin & @djbrooke -- has IQSS done any work on this? We'd otherwise likely want to put this on our Q1 roadmap. I think @qqmyers had some initial thoughts on a simple GUI integration unless you're dead set against that? I think the concerns with this for self-deposit repositories could be addressed by making it superuser only |
|
Thanks @adam3smith for the ping. @scolapasta - let's check in about this later this week |
|
@kcondon - It looks like you have the Archiver partially set up: I think you've got :ArchiverClassName set to the DuraCloud class, but don't have the java properties for duracloud.username and maybe duracloud.password set in glassfish. Since we've dropped the DuraCloud credentials, I think if you delete the :ArchiverClassName setting, you should be able to publish and/or update the current version. If you want to test with archiving, I think we have to recreate a duracloud account. (The insides of the Archiver classes haven't changed, so nominally they should not be affected by this PR. And I know the archiving works here with update current version...) |
|
Also looks like I missed getting the success/fail messages in Bundle - I'll add those now... |
|
@qqmyers OK, I can save current version and page updates without bundle error. I've removed Archiver and DuraCloud settings but am still seeing a server log error when I update current version: [2019-02-28T16:42:48.299-0500] [glassfish 4.1] [WARNING] [] [edu.harvard.iq.dataverse.util.ArchiverUtil] [tid: _ThreadID=51 _ThreadName=jk-connector(2)] [timeMillis: 1551390168299] [levelValue: 900] [[ [2019-02-28T16:42:48.300-0500] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=51 _ThreadName=Thread-9] [timeMillis: 1551390168300] [levelValue: 1000] [[ |
|
@kcondon - since there are two possible transactions (the update of the version and, separately, an archive submission, if configured), there are four possible outcomes - success/fail of step 1 and success of step 1 with success/fail of the second. The first should succeed unless you make parallel edits in another browser, so I think you could test the fail path if desired. The way you were configured before - with :ArchiverClassName set is a way to test the update version succeeds/archiving step fails path. The only one that requires more to test would be setting up Duracloud to make the archiving also succeed (but again, that's the one we're set up for.) |
|
Would you fix #5590 as part of this pr? I'm not seeing on 4.11 branch I don't have workflows defined according to: |
|
@qqmyers Updating a file to be restricted or unrestricted allows updating in current version but fails with error in UI, not in server log. |
|
@qqmyers Did you make any change to the publish dataset api for this? How would one specify current version? |
|
@kcondon - if I try this in v4.11-qdr, I only see the 'major' version option. I don't think I changed anything w.r.t. the decision to allow a minor version (DatasetVersion.isMinorUpdate()), so you may have found a bug there. Can you get to the minor version option doing a restrict/unrestrict on dev or v4.11? |
|
@kcondon - yes - you can provide a type updatecurrent instead of major or minor in the publishDataset api call. |
|
@qqmyers Yes, I can see minor option in 4.11 when changing file restriction. Is the doc updated for the api change? |
|
@kcondon - my bad w.r.t the major version - my test dataset had an extra file. When I just restrict/unrestrict, I see the update current option. It works for me, so I'll look at what may be different than in the PR. |
|
@qqmyers Thanks, for what it's worth, updatecurrent for file restriction works for the publish api. |
|
@kcondon - hmm - the only way to get the IllegalCommandException is to get false in the if statement on line 96 of CuratePublishedDatasetVersionCommand.java: That means that somehow the filemetadata for the draft or prior published version was not found - versus anything being wrong with the logic to set the restricted state. Are you able to repeat the problem? Any thoughts on how/why the filemetadata might not be there? (perhaps some sequence of events with no page refreshes leaves a stale state I'm not catching?) I'll look for a way to trigger the problem but any clue you can find w.r.t. it being occasional/only under certain circumstances would be helpful... |
|
@qqmyers I am now unable to reproduce the issue. So, I'm ok with this as is. I'll try it a couple more times to be sure but then, after docs are added, I will merge it. |
|
@pdurbin Haven't you been reading the comments? ;) |
|
@kcondon ah, now I see some chatter about "updatecurrent" API testing. Good! 😄 |
|
@kcondon - I made a minor add to @pdurbin docs (thanks for that!), so I guess its good to go. I am concerned that you had that one error. My only guess right now is that there's some way to get a stale page. If that's true, I should be able to refresh from the db to fix it, but I don't want to to do that if we can't duplicate the problem. On the good side - if it is something stale, a page refresh will fix it, so there's a work around... -- Thanks! |
Originally posted to Community list where @pdurbin linked to a previous request on the list for similar functionality.
There are two main use cases for us:
Especially 1.) can occur many times over the lifespan of a dataset and we think bumping up the version number, even with "minor version bump", especially when you see something like "Version 1.12" for replication data, may cause confusion/wasted time at best (with people spending time checking changes between versions) and suspicion at worst ("Why was this replication data update after the fact?").
I understand there are concerns especially among people running DV as a self-service repository, so this needs to be limited to the right permissions. On our end, we would be happy with limiting this to super users, but I can see the case for groups wanting to do this within their own (sub-)Dataverses, so there may be a case for allowing this for Dataverse admins but I have no strong feelings about this either way.
The text was updated successfully, but these errors were encountered: