Oliver
[EMAIL PROTECTED] wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
