[Zope-CMF] Re: [CMF-checkins] CVS: CMF/CMFCore - CatalogTool.py:1.30.4.7

[Sidnei da Silva]

| >4. The user that created the object *is* set as the owner
| 
| Do you mean the user is given the Owner role?

I mean getOwner() returns the user that created the object, without
doing anything special.

| >7. Then for each local role, if the role is on the set of roles that
| >have the view permission, add the user to result (note that the user
| >that created the object *is* owner, but doesnt have a local role of
| >Owner, so he doesnt get into this list)
| 
| Why doesn't the user have the Owner role at this point?  That's the way 
| it's supposed to work.

getOwner() returns the user, but he doesnt have a local role of Owner.

| >8. The owner role is deleted from the result.
| >
| >So, at this point allowedRolesAndUsers would contain ['Manager'], and
| >the user that created the object cant find it on a search.
| >
| >What solution you propose? Using Creator() instead of getOwner()?
| >(Note that Creator() is currently returning the result of getOwner(),
| >which I pointed out months ago, but no one agreed on a solution for
| >that).
| 
| That's even more broken.  I had forgotten about that.  Creator() then 
| implements a high-level, supposedly modifiable property using a 
| low-level, deep-in-the-guts-of-executable-security method.  In fact, 
| only executable objects like Python scripts are really supposed to have 
| a getOwner() method.
| 
| Ugh, naming is both important and hard.  I can see why people have 
| gotten confused about getOwner().

Whats your suggestion to fix this?

-- 
Sidnei da Silva (dreamcatcher) <sidnei@x3ng.com.br>
X3ng Web Technology <http://www.x3ng.com.br>
GNU/Linux user 257852
Debian GNU/Linux 3.0 (Sid) 2.4.18 ppc

In the long run, every program becomes rococco, and then rubble.
		-- Alan Perlis