Project

General

Profile

Bug #4391

Current scheme of naming revisions of datapackages under Morpho seems faulty

Added by Sandeep Namilikonda over 9 years ago. Updated about 9 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
client
Target version:
Start date:
09/16/2009
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4391

Description

Suppose a data package has undergone a number of revisions, say v1 - v10.

Opening an older revision of an assessment, say v6, making a few changes
and saving it would overwrites the existing v7.

So, effectively, an older version has been overwritten. But, the latest revision
for that assessment in the list of data packages under Morpho is still v10. If you close and open the datapackage, it still opens v10, which is not the most current one (v7 is).
This behavior is counter intuitive.

Further, we notice that making changes to v6 and saving it as v7 automatically
disables revisions v8 and v9. This is in line with the expected behavior. Yet,
the latest revision getting a number v7 and overwriting the older copy of v7
should be deemed absolutely faulty. Ideally, v8, v9, and v10 should be
disabled/deleted or revisions to v6 should result in v11.

History

#1 Updated by ben leinfelder about 9 years ago

I'm not positive, but I think the intent is that you would "revert" to an older revision then "save a duplicate" of that to get a whole new document. Should see how the normal Morpho handles this for EML.

#2 Updated by Redmine Admin over 5 years ago

Original Bugzilla ID was 4391

Also available in: Atom PDF