Hi, On Thu, Oct 31, 2013 at 2:03 AM, Angela Schreiber <[email protected]> wrote: > hi > > if i remember correctly the move case you mentioned below is > covered by the commit hook (see VersionablePathsTest). if there > are cases that don't work properly i would be glad if you could > provide add a test case (patch for the fix is optional).
No, this is not the issue. The main problem of the versioning is, that the versionable path is not recorded when creating a version. this is IMO a flaw in the spec. In CQ we added this information in order to be able to restore a deleted node. So I was happy to learn that oak now stores this information - but as I mentioned, on the wrong node. > as far as the location of the versionable path is concerned > i am not convinced that moving it the versions will add any > benefit. my plan was to bind accessibility of the whole > versionhistory associated with a versionable node to the > permissions enforced on that very node in a given workspace. so, > in other words the accessibility may change if the effective > permissions change for that node (by changing the ac content > or by moving around the node or any of it's ancestors). ok, so this is a different use case and does not solve the problem I mentioned above. however, moving a node to a different location might also change it's accessibility, and it's questionable if this is bound to the version history or the version itself. Example: * you have node "/public/A" that you version, in V1.0, * and then move to "/private/A" that you version, in V2.0. * and then move it back to "/public/A" and version V3.0 assuming the the versionable paths still exist when accessing the versions, I would assume that the versioned document V2.0 is still private, and 1.0 and 3.0 are public. > i guess what you intended to achieve by moving it to the > versions themselves is to version the effective permissions > themselves... no. > but that would not require moving the paths > information to the version but rather copying the complete > effective permissions to the version including all effective > permissions present to the whole subtree that is copied to > the version node. that's IMHO not feasible. why not? :-) > another disadvantage of moving it to the version information > is that you can't determine the accessibility of the version > history node. i had a similar issue when it comes to the > intermediate nodes the make up the structure of the version > storage and didn't find a satisfying solution. I don't think that the version history node itself is of much value. you could guess the existence of a node with the respective UUID (which is encoded in the VH name) but this is IMO not a security problem. or you can use the versionable path recorded in the last version to calculate the permissions for the version history. > and last: > you are right regarding collisions in the workspace name. but > i would suggest that we just escape the name. ok. > as far as renaming/removing workspace is concerned: renaming is > not supported by JCR afaik. creating new workspace as well as an > existing workspace (once we actually support multi-workspace setup) > could be covered by the corresponding commit hook, couldn't it? sure. regards, toby > > > On 10/30/13 11:52 PM, "Tobias Bocanegra" <[email protected]> wrote: > >>Hi, >> >>oak now has rep:VersionablePaths which record the paths (per >>workspace) of the versionable node. >> >>I think this is wrong to store this on the nt:versionHistory node, >>since a node can be moved in between checkins. so I think it should be >>recorded on the nt:version node. >> >>I also find it dangerous to just use the workspace name as property >>name for the path, as it makes it harder to list the paths, if ever a >>workspace is removed or renamed (not that this is supported). also, it >>does not work with "funny" workspace names, such as: "jcr:uuid" :-) >> >>I suggest the following structure: >> >>/jcr:system/jcr:versionStorage/..../ [nt:versionHistory] >> /1.0 [nt:version] >> /rep:versionablePaths >> + workspace1name "/path/..." >> + workspace2name "/path/..." >> + workspace3name "/path/..." >> >>OR a MV value: >> >>/jcr:system/jcr:versionStorage/..../ [nt:versionHistory] >> /1.0 [nt:version] >> + rep:versionablePaths [ >> "workspace1name/path/", >> "workspace2name/path/", >> "workspace3name/path/" >> ] >> >>WDYT? >> >>Regards, Toby >
