On Thu, Oct 31, 2013 at 2:55 PM, Angela Schreiber <[email protected]> wrote: > hi > > but you don't gain anything when you store the path of the versionable > node with the version. yes, I know the versionable path, in case I want to restore a deleted node.
> the evaluation will be excuted against the > current persisted effective permissions present on the versionable > node referred to by that path not the state when it was 'private'. in my example, there are 2 locations. /public/A and /private/A and the node was moved in between the chekins. > IMO the most common case is that a given node is checked-in multiple > times -> you would always get the latest effective permissions on the > versionable node :-) yes. > there might be cases where the node is moved around and checked-in > in the mean time -> if the versionable location does no longer exists > you wont get any reliable permission result when evaluating > the original path... and in addition it will be very hard to understand > how the effective permissions are being calculated on version content. > in the worst case the result will be quite arbitrary as the original > 'private' permission is gone and you just get the inherited permissions > (most probably not what you wanted if i try to figure out what use > case you are referring to). in case the recorded path is gone, you can still fallback to the path recorded on the base version (which would be the same as "your" current path on the version history). > so, if you really wanted to have the permissions effective at the time > the version was created you have to compile the effective permission > for the version, each property and each item contained in the frozen > node into the version store and then do that for all workspaces containing > a corresponding item for each and every of these items. that's what > why i think it's not feasible :-) for sure it will not work properly > if you just store the path of the versionable node with the versions. sure. but I think by storing the path in the versions we gain 2 things: 1. we can more accurately figure out the permissions for the version 2. we know the path when the version was created, which helps in a general document management case for finding and restoring deleted nodes. Regards, Toby > On 10/31/13 6:36 PM, "Tobias Bocanegra" <[email protected]> wrote: > >>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 >>> >
