Any news or comments about this issue? Regards, Peter
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 06, 2004 10:55 > To: [EMAIL PROTECTED] > Subject: RE: Structure of history folder > > > Yes, it sounds pragmatic and good to me too. Unfortunately, both specs > (DeltaV and ACL) are silent WRT this problem. Some time ago we, at > Software AG, tried hard to find an appropriate solution ... but didn't > succeed :( > > Here are some questions/remarks: > > A) AFAIU the idea is to let *all* VRs of an history somehow > *dynamically* "inherit" the ACLs from another resource. > Right? Could it > be: > 1) from one specific VR of the history? > a) which one? root VR? latest VR? (there can be many latest) > b) how does it get its ACL initially? > 2) from a VCR? > a) what if multiple VCRs are related to the same history? > b) take the VCR from an assumed "global workspace"? > > B) If A-2 is correct: what if the VCR is deleted and the > history remains > ... what are then the persmissions of the history? > > C) If all VRs of a history should have the same set of permissions, > these are ideally defined at the VHR and inherited over the namespace > hierarchy? > > D) The ACL spec defines a strange "inheritance" mechanism over the > DAV:inherited-acl-set property: > "This protected property contains a set of URLs that identify other > resources that also control the access to this resource. To have a > privilege on a resource, not only must the ACL on that resource > (specified in the DAV:acl property of that resource) grant the > privilege, but so must the ACL of each resource identified in the > DAV:inherited-acl-set property of that resource. Effectively, the > privileges granted by the current ACL are ANDed with the privileges > granted by each inherited ACL." > > Could this property help? Did you (Mike O.) use it in your solution? > > Regards, > Peter > > > -----Original Message----- > > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 05, 2004 09:02 > > To: Slide Developers Mailing List > > Cc: Nevermann, Dr., Peter > > Subject: Re: Structure of history folder > > > > > > To me this sounds good. What does Peter say to all this as I > > understand > > he has written most of the DeltaV code. > > > > Peter? > > > > Oliver > > > > Michael Smith wrote: > > > Michael Oliver wrote: > > > > > >> 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, > > > > > > This sounds fairly reasonable. My suggestions before were > > not intended > > > as a "this is the way it should work", but more intended as > > a way to > > > spark some discussion of the possible approaches - looks > > like it worked :-) > > > > > > The "generations" stuff looks interesting - but somewhat > > unrelated. I > > > think we can (should) probably implement just 1 & 2 initially. > > > > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
