How to give delete permission to owner

[George Lee]

> There is no reviewer, so each member is in charge of his own content and
> decide if this content can be published, private or restrict.
> On the web site, there is several public folders and the manager (me) decide
> which member(s) can publish on which folder(s). To achieve this, manager
> affects a "publisher" local role to some members for specific a folder.
> For this site I want that if a member can author and publish a content he
> also can delete the content he have authored (that's logical in my context).


One site of mine is similar in that there is no reviewer. I agree that it is
logical that a member can delete content he/she has authored.

One possibility that I think introduces less security complications is this:
create a new workflow state "deleted" and a new workflow transition "delete".
Have that transition execute an external method (to bypass security) that
deletes the object -- see http://docs.neuroinf.de/PloneBook/ch8.rst for an
example of how this happens.

It feels like bad practice to have a workflow like the one you suggest that is
too specifically tailored to how items are used in part of a site, because it
denies flexibility later. As my site grows in complexity, shortcuts I've taken
have come back to bite me in the rear time and again, and now I am working very
hard to make sure the programming is very clean and robust.

I understand if you think this solution is too complicated but I'm throwing it
out there.

Peace,
George



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users

[Jean-Charles DUFOUR-2]

Correction :

For folder my workflow assign these permission for 'delete objects':
Acquire : unchek
Anonymous : uncheck
Authentificated : uncheck
Manager : check
Member : check
Owner : check

For non-folder content my workflow assign these permission for 'delete
objects':
Acquire : unchek
Anonymous : uncheck
Authentificated : uncheck
Manager : check
Member : uncheck
Owner : check

But ATTENTION if you read this thread there is some defect/deficiency in the
use of this ("my") SOLUTION  :
1. member can delete a sub-folder even if they are not the owner of this
folder
2. and member can still cut/move non-folder content using tab when they use
the folder content tab

"Jean-Charles DUFOUR" <dufour.jeancharles@...> a
écrit dans le message de news: dne6kd$9ir$1@......

> Hi,
>
> According to my tests, you was rigth: the default settingd for the
> permissions of new objects can be determine by the workflow of these new
> objects.
> In my case (wich is particular) I have used this solution: I have added
> the permission 'delete objects' to the 2 workflows who manage new folder
> and new non-folder objects in my site. For all the state of these
> workflows I've check only "Acquire", "manager" and "owner" for the 'delete
> objects' permission.
> Then each object added by a user (a member) in my site can be deleted only
> by the manager(s) or the owner(s) of this object.
> It's exactly what I want.
> It's a shame that I don't know a nice method to obtain this behavior only
> for designated folder and not for all the site. But it's OK like that for
> my site.
>
> Thank for your help
>
>
>
> "Rene Pijlman" <rene@...> a écrit dans
> le message de news:
> ga1kp11drcqvvr8f2ep1oe6i2srvf84ej8@......
> Jean-Charles DUFOUR:
>>We (You) are close to the result...but the problem is now how to do in
>>order
>>to have this permission set by default. Because at present the default is
>>for documents added : Aquire is check and 'delete objects' is unchek for
>>everybody
>
> What determines the default settings for the permissions of new
> objects? Good question. I don't know. My guess would be: the
> containing folder. What else? So that would not help you in this
> case.
>
> If there's no better solution, you could make this permission
> managed by separate workflows for folderish and non-folderish
> objects. Basically assign the permissions you now have figured
> out in all states. Then hit the 'Update security settings'
> button once.
>
> Now the remaining question is: what determines the default
> settings of permissions that are managed by a workflow on new
> objects? The containing folder or the workflow? I assume it's
> the workflow, and that would be your solution, but I'm not sure.
>
> --
> Rene Pijlman
> http://www.applinet.nl/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click 

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users