I believe that the current permissions on the current version should be applied to all versions and not the permissions at the time the version was created. This is how we did it with Livelink and our reasoning at the time was as follows:
1) If a user is removed from access to the current version, this is usually because the owner of the document wants the content of the document removed from view for that user (or group). 2) If a user is granted access to a document, then all previous versions are also granted, for a similar reason. 3) Access to specific versions without access to all versions was possible in Livelink with a concept we called "generations" that allowed a specific version of a document to appear to the system as a separate "generation" document. Michael Oliver CTO Matrix Intermedia Inc. 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(520)844-1036 -----Original Message----- From: Michael Smith [mailto:[EMAIL PROTECTED] Sent: Monday, May 03, 2004 8:33 PM To: Slide Developers Mailing List Subject: Re: Structure of history folder Oliver Zeigermann wrote: > Michael Smith wrote: > >> >> b) We still (with OR without this change) have the problem that the >> history implementation is very broken if you're using access control. >> It's a hard problem (the semantics of full access control across a >> versioned repository could be difficult to define), but the current >> approach basically just ignores the ACLs entirely - so anyone can read >> objects from their history locations (obviously, this requires >> _finding_ those objects, which isn't easy, but it's not too hard >> either). I think we really need to think about what solutions we can >> come up with for this problem. > > > Anything you can propose to get this started? > > Oliver > I can try... One possible set of semantics is as follows (note: the following extensively uses DeltaV terminology, it'll be hard to follow if you haven't read the spec): Normal ACLs do not apply to /history. Or perhaps they do - but generally, the only ones set will be inheritable ones from /, we can deny those same permissions in /history. When a version resource (VR) is created from some versioned resource, the set of applicable ACLs is computed (from the versioned resource) and set on this VR (note that this isn't just copying them, because we want inheritable permissions to come through as well). I haven't thought through all the details of this, but I think it can be done. This means that, when a VR is created, _that_ version (but not other versions) has the permissions that the versioned resource had _at the time this version was created_. Problems: What if you want to retrospectively change the permissions (e.g. I create version 1, then set permissions correctly, then create version 2. I realise at that point that version 1 had some confidential information in it, should I be able to set permissions explicitly on that older version? Should, instead, the _current_ permissions on the versioned resource always be applied all versions? What about VHRs? What permissions do we set on those? If permissions on a resource are set such that all users except the person who created the resource cannot even see that the resource exists, it makes sense that the VHR cannot be seen either. But there's only one VHR, so which set of permissions do we use? This problem is easier if we take the "current permissions apply to all versions" approach. Does anyone know what existing systems (not neccesarily deltav) do? I have no personal experience with any other system that provides both versioning and full ACLs. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
