Just a follow up on the issue described below. It appears that these funny content objects that are marked as read-only were created by the 1.1 code that handled reverting between versions.
In 1.1, the SparseListVersionsServletHandler (which ultimately handles requests like /path.versions.json) would return a list of all versions, with each version including the full JSON tree of its node. When reverting to a previous version of a document, the UI would take this JSON tree and import it as the current version (via the LiteJsonImporter). Since this imported JSON tree was a full dump of the version node, it included the version-specific properties like _readOnly, _nextVersion, _previousVersion, etc.. Since nothing stops a new node being created with these properties, we were left with some active content nodes marked as read-only. And when the DocMigrator tries to migrate these, it throws an AccessDenied exception. So I think I'll have to find a way to clear the readOnly flag from the content nodes affected by this. Mark Mark Triggs <[email protected]> writes: > The other issue we hit--which might just be a legacy data issue--was > migrations failing for content objects that the '_readOnly' flag set to > 'Y': > > "id2814416": { > "_created": 1332976244517, > "_createdBy": "abc123", > "_id": "UmtvQHksEeGFT76YfwAAAQ+", > "_lastModified": 1332976690260, > "_lastModifiedBy": "abc123", > "_nextVersion": "Sj3GsHksEeGFT76YfwAAAQ+", > "_path": "kQveymeNie/id2814416", > "_previousVersion": "23RD0XkrEeGFT76YfwAAAQ+", > "_readOnly": "Y", > > Sparsemap's ContentManagerImpl explicitly checks for this flag and > throws an AccessDeniedException if it's set, so the migration couldn't > run on these objects. To get around this I ended up commenting out the > check, running the affected objects through the migration, then putting > the check back in again. Does anyone know if this flag is still being > set? I guess this might crop up again during future migrations. -- Mark Triggs <[email protected]> _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
