In article <[EMAIL PROTECTED]>,
Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:04 PM 12/12/00 -0500, BS wrote:
> >Do DataSkins have ownership? I want to give multiple users the ability to
> >add objects to a rack and only allow the 'owner' to view/edit the object.
> DataSkins stored in Racks do not participate in the Zope ownership
> mechanism, nor the creation of the 'Owner' role.  This is because they are

To clarify: if you just want Owner roles, as opposed to Ownership[1][2][3],
you can do that with totally-non-ZODB objects.  I have a couple
different applications where totally SQL- or LDAP- are given local roles
(Owner and others) to implement security as you describe. 

The way we do it requires LoginManager to be in use, or to have patched
Zope with improvents to the local roles support (LM effectively hotfixes
these in for its own users). Then our DataSkins-based ZClasses also
mix in AppTabs[4], which has a get_local_roles_for_user() which tries
a LocalRolesForUser() method if it exists, otherwise falls back to older
means. Finally, you can define LocalRolesForUser to compute local roles
for the accessing user by whatever rules it wants.

[1] People may complain about ZPatterns terminology, but at least we
have the sense not to use the same word for two entirely different
concepts! :-)

[2] And I don't know why you'd care about Ownership for your objects in
this example...  it doesn't seem meaningful for these sorts of non-code

[3] Actually, maybe you could write SkinScript to provide the _owner
attribute. But see [2]...

[4] Unreleased product, still in some flux.  It mainly provides fancier,
more flexible version of Zope's management tabs, suitable for use in an
application (that is, suitable for exposing to users, not just
developers). It also has some local roles hooks as mentioned.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to