Bug #5882

Get a system metadata version number error when morpho tried to change the access policy of a network document

Added by Jing Tao almost 8 years ago. Updated almost 8 years ago.

morpho - general
Target version:
Start date:
Due date:
% Done:


Estimated time:


When I tried to change the access rule of a network document, i got this error:

The requested system metadata version number 0 differs from the current version at 1. Please get the latest copy in order to modify it.

Here is what i did:

1. Used the new data package wizard to create an new eml only document and saved it to the network.

2. Chose Documentation|Access Information to add a new access rule and got an error - the cn doens't have the id and please try again later.

3. A while later, i clicked the Documenation|Access Information again (I didn't close the data package) and I saw the new rules i added in previous step (this is a little bit confusing - users may think the new rule already has been added). Then i clicked the okay button and got this error.


#1 Updated by ben leinfelder almost 8 years ago

If you reopen the package, you should get the updated SystemMetadata (serial version 1) and be able to update the access policy at that point. When the CN harvests the object from the MN it increments the serial version number (because it modifies some other system metadata fields). We want users to get have the latest version when they are updating.

I agree that it is a little confusing to have the changes you made still there even after an error, but they will go away if you close the package. The alternative would be to save the existing access policy and in case of errors we would overwrite their modifications. But If I'd spent a while writing access rules and then they were all erased because of an error I'd be pretty upset. But I guess with the serial version error I'd have to close the package anyway and loose my changes.

We could just grab the latest serial version number when we make any setAccess call, but that defeats the purpose of having the field in the first place.

#2 Updated by ben leinfelder almost 8 years ago

Until we have a better solution, I have changed the code to always look up the latest serialVersion from the CN before calling setAccessPolicy (and setReplicationPolicy). This means we will unknowingly overwrite any changes that were made by, say, someone else.
Ideally we would refresh the UI with the the access policy found on the CN when we detect that the versions do not match. But we also discussed at the most recent CCIT meeting making the MN authoritative for access policy changes.

#3 Updated by Redmine Admin almost 8 years ago

Original Bugzilla ID was 5882

Also available in: Atom PDF