[ZPatterns] DataSkin object ownership
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. When a user adds a DataSkin to a rack does he get ownership of the object? I can't seem to get the ownership information for these objects. Is there a way to do this? BTW - I'm talking about virtual object that totally live in MySQL. Thanks, -Ben
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. When a user adds a DataSkin to a rack does he get ownership of the object? I can't seem to get the ownership information for these objects. Is there a way to do this?
DataSkins stored in Racks do not participate in the Zope ownership mechanism, nor the creation of the 'Owner' role. This is because they are not being stored via the normal ObjectManager protocols. If you want this behavior, you'll need to use Folders w/Customizer support, which let you use most of DataSkins' dynamic features with "almost ordinary" Zope objects.
BTW - I'm talking about virtual object that totally live in MySQL.
Folders w/Customizer Support require the DataSkins' primary storage to be in the ZODB.
In article <200012130255.SAA29869@zope.codeit.com>, Phillip J. Eby <pje@telecommunity.com> 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 objects. [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.
Ty Sarna wrote:
AppTabs[4]
[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.
Ooo.... sounds very cool... any chance of a release? I had a proposal on dev.zope.org for something similar (Multi-Row Manage Tabs, I think, but it was a while back :-S) cheers, Chris
"Phillip J. Eby" wrote:
DataSkins stored in Racks do not participate in the Zope ownership mechanism, nor the creation of the 'Owner' role. This is because they are not being stored via the normal ObjectManager protocols.
Hurm... to what extent do they participate in Zope's Security Mechanisms? cheers, Chris
At 11:43 AM 1/3/01 +0000, Chris Withers wrote:
"Phillip J. Eby" wrote:
DataSkins stored in Racks do not participate in the Zope ownership mechanism, nor the creation of the 'Owner' role. This is because they are not being stored via the normal ObjectManager protocols.
Hurm... to what extent do they participate in Zope's Security Mechanisms?
They participate fully, as long as you are not trying to use the DataSkin class itself without mixing it with a Zope base class that supports security. Note that even though ownership and the Owner role are not set up by default for rack-mounted DataSkins, you can still set them up manually or programmatically, if you are so inclined. The only reason they're not set up is because it's ordinarily the job of an ObjectManager to set them up on items added to the ObjectManager, and a Rack does not relate to its DataSkins as an ObjectManager.
participants (4)
-
BS -
Chris Withers -
Phillip J. Eby -
tsarnaļ¼ endicor.com