Bug #4391
openCurrent scheme of naming revisions of datapackages under Morpho seems faulty
0%
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.
Updated by ben leinfelder about 15 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.