Commit 2aa41ef1 authored by Amos Latteier's avatar Amos Latteier

Changed Ownership tab. Got rid of implicit/explicit ownership. Now you just...

Changed Ownership tab. Got rid of implicit/explicit ownership. Now you just choose to take ownership of subobjects (or not) when taking ownership.
parent 957b2597
......@@ -85,8 +85,8 @@
__doc__='''Support for owned objects
$Id: Owned.py,v 1.5 2000/07/10 13:23:15 brian Exp $'''
__version__='$Revision: 1.5 $'[11:-2]
$Id: Owned.py,v 1.6 2000/10/12 16:55:21 amos Exp $'''
__version__='$Revision: 1.6 $'[11:-2]
import Globals, urlparse, SpecialUsers, ExtensionClass, string
from AccessControl import getSecurityManager
......@@ -158,27 +158,28 @@ class Owned(ExtensionClass.Base):
return owner
changeOwnership__roles__=()
def changeOwnership(self, user,
def changeOwnership(self, user, recursive=0,
aq_get=aq_get, None=None,
):
"""Change the ownership to the given user, make the
ownership acquired if possible."""
"""Change the ownership to the given user. If 'recursive' is
true then also take ownership of all sub-objects, otherwise
sub-objects retain their ownership information."""
new=ownerInfo(user)
if new is None: return # Special user!
old=aq_get(self, '_owner', None, 1)
if old==new: return
# See if there is an _owner in the instance. If it is a
# class attribute we leave it alone.
if self.__dict__.get('_owner', _mark) is not _mark:
# Hm, maybe we can acquire ownership
del self._owner
self.changeOwnership(user)
else:
if old is not UnownableOwner:
self._owner=new
if old is UnownableOwner: return
for child in self.objectValues():
if recursive:
child.changeOwnership(user, 1)
else:
# make ownership explicit
child._owner=child._owner
if old is not UnownableOwner:
self._owner=new
def userCanTakeOwnership(self):
security=getSecurityManager()
......@@ -189,8 +190,10 @@ class Owned(ExtensionClass.Base):
if owner == info: return 0
return security.checkPermission('Take ownership', self)
def manage_takeOwnership(self, REQUEST, RESPONSE):
"""Take ownership (responsibility) for an object.
def manage_takeOwnership(self, REQUEST, RESPONSE, recursive=0):
"""
Take ownership (responsibility) for an object. If 'recursive'
is true, then also take ownership of all sub-objects.
"""
security=getSecurityManager()
want_referer=REQUEST['URL1']+'/manage_owner'
......@@ -200,8 +203,10 @@ class Owned(ExtensionClass.Base):
if (want_referer != got_referer or security.calledByExecutable()):
raise 'Unauthorized', (
'manage_takeOwnership was called from an invalid context'
)
self.changeOwnership(security.getUser())
)
self.changeOwnership(security.getUser(), recursive)
RESPONSE.redirect(REQUEST['HTTP_REFERER'])
def manage_changeOwnershipType(self, explicit=1,
......
......@@ -6,34 +6,37 @@
<BODY BGCOLOR="#FFFFFF" LINK="#000099" VLINK="#555555">
<dtml-var manage_tabs>
<dtml-var title_and_id> is
<p>Almost all Zope objects can be owned. When you create an object you
become its owner. Ownership matters for method objects since
it determines what roles they have when they are executed. See the
<i>Proxy Roles</i> view of method objects for more information.</p>
<p><b><dtml-var title_and_id> is
<dtml-if owner_info>
<dtml-with owner_info mapping>
owned <dtml-if explicit> directly
<dtml-else> indirectly (through acquisition)
</dtml-if> by &dtml-id; (&dtml-path;).
<dtml-if userCanChangeOwnershipType>
<form action="manage_changeOwnershipType">
<dtml-if explicit>
<input type="hidden" name="explicit" value="">
<input name="submit" type="submit" value="Make ownership implicit (acquired)">
<dtml-else>
<input type="hidden" name="explicit" value="y">
<input name="submit" type="submit" value="Make ownership explicit">
</dtml-if>
</form>
</dtml-if>
owned
by &dtml-id; (&dtml-path;).
</dtml-with>
<dtml-else>
unowned.
</dtml-if>
</b>
</p>
<dtml-if userCanTakeOwnership>
<p>If you have the <i>Take Ownership</i> roles you can take ownership
of an object. You should do this when the owner of an object is
deleted from Zope. Normally when taking ownership you should also take
ownership of sub-objects as well.
</p>
<form action="manage_takeOwnership">
<input name="submit" type="submit" value="Take ownership">
<p><input name="submit" type="submit" value="Take ownership of object">
</p>
<p><input name="recursive" type="checkbox" checked>
Also take ownership of all sub-objects.
</p>
</form>
</dtml-if>
......
......@@ -26,24 +26,6 @@ Ownership: Manage ownership.
are *unowned*. An unowned executable object executes with the
permissions of the user running the object.
There are three possible states of ownership that a Zope object
may be in. The object may be *unowned*, it may be *owned directly*
or it may be *owned implicitly*. If an object is owned directly,
the ownership information is stored in the object itself. If an
object is owned implicitly, it acquires its ownership information
from its container (which may in turn acquire its ownership
information from its container, and so on).
When Zope automatically assigns ownership to newly created or
copied objects, it tries to use implicit ownership if
possible. This makes it easier to change the ownership of many
objects at one time without having to visit each object
directly. For example, if everything in the folder 'research' is
owned by Fred and you want to change the ownership of everything
in the folder to Jim, you only need to visit the 'research' folder
and change the ownership there if all of the objects under
'research' are owned implicitly.
It is possible to remove a user in your Zope installation while
objects that were owned by that user remain (for instance, someone
in your organization moves on, so you remove his account on your
......@@ -51,16 +33,14 @@ Ownership: Manage ownership.
by that user still have ownership information that refers to that
user. This will not cause an error, but it is important to
understand what happens to Zope objects whose owners no longer
exist.
This is most important for "executable" objects. Usually, the
abilities of executable objects are constrained by the abilities
of the object's owner as well as the user causing the object to
execute. If Zope cannot find the user that the executable's
ownership information refers to when it tries to execute the
object, it will use the special 'nobody' or anonymous user
instead. The 'nobody' user has very minimal privileges, so you
should take this into account when deciding what to do about a
exist. This is most important for "executable" objects. Usually,
the abilities of executable objects are constrained by the
abilities of the object's owner as well as the user causing the
object to execute. If Zope cannot find the user that the
executable's ownership information refers to when it tries to
execute the object, it will use the special 'nobody' or anonymous
user instead. The 'nobody' user has very minimal privileges, so
you should take this into account when deciding what to do about a
user's owned objects when you delete the user. If the user had
DTML documents or other executable objects that depended upon
their owner to have a higher level of privilege than the 'nobody'
......@@ -73,14 +53,6 @@ Ownership: Manage ownership.
**Note: For this operation you have the 'Take ownership' role.**
'Make ownership implicit (acquired)' -- Remove ownership
information for this object so that it is acquired from its
container.
**Note: This operation will fail if it would result in a change
of ownership.**
'Make ownership explicit' -- Add ownership information to this
object.
'Also take ownership of all sub-objects' -- Gives you ownership of all the current object's sub-objects when you take ownership of the current object. Normally you should leave this option checked.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment