Restrict create privilege where owner of parent is self.

Next topic

Author	Message
Nathan Sharp	Friday 29 September 2006 10:42:22 am I've looked around a little and haven't found this yet, so my apologies if it has already been requested. I am soon to be administering an image gallery site for a group of people. I would like each person to have create/edit/remove permissions for their own gallery. Obviously I could manually create top-level folders and roles for each person that do this, but I was hoping for something a little simpler. If I could restrict the create privilege to only allow people to create new nodes if the parent node is already owned by them, I think I could implement this with a static list of roles and a user group. 1) Allow users to create folders directly in a top-level node, but not in the subtree 2) Allow users to create folders, galleries, images in any sub-tree of the top-level <i>where they own the parent</i>. 3) Allow users to edit/remove any of the above that they own. Is this reasonable? Is there some way to accomplish it that I haven't thought of? Regards, Nathan P.S. In a matter of a few hours I was able to put together a site for this group that seriously wowed them. Thanks!
Kristof Coomans	Saturday 30 September 2006 6:05:31 am Hi Nathan There was a ParentOwner patch (by Gabriel Ambuehl) submitted for eZ 3.8 on the sdk-public mailinglist (http://lists.ez.no/pipermail/sdk-public/2006-March/002046.html). It didn't make it's way into it but it's definitely worth a try. independent eZ Publish developer and service provider \| http://blog.coomanskristof.be \| http://ezpedia.org
Nathan Sharp	Monday 02 October 2006 6:00:55 am That looks right on! Thanks!

Author

Message

Friday 29 September 2006 10:42:22 am

I've looked around a little and haven't found this yet, so my apologies if it has already been requested. I am soon to be administering an image gallery site for a group of people. I would like each person to have create/edit/remove permissions for their own gallery. Obviously I could manually create top-level folders and roles for each person that do this, but I was hoping for something a little simpler. If I could restrict the create privilege to only allow people to create new nodes if the parent node is already owned by them, I think I could implement this with a static list of roles and a user group.

1) Allow users to create folders directly in a top-level node, but not in the subtree
2) Allow users to create folders, galleries, images in any sub-tree of the top-level <i>where they own the parent</i>.
3) Allow users to edit/remove any of the above that they own.

Is this reasonable? Is there some way to accomplish it that I haven't thought of?

Regards,
Nathan

P.S. In a matter of a few hours I was able to put together a site for this group that seriously wowed them. Thanks!

Kristof Coomans

Saturday 30 September 2006 6:05:31 am

Hi Nathan

There was a ParentOwner patch (by Gabriel Ambuehl) submitted for eZ 3.8 on the sdk-public mailinglist (http://lists.ez.no/pipermail/sdk-public/2006-March/002046.html). It didn't make it's way into it but it's definitely worth a try.

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Nathan Sharp

Monday 02 October 2006 6:00:55 am

That looks right on! Thanks!

eZ debug

Timing:	Jan 18 2025 16:12:12
Script start
Timing:	Jan 18 2025 16:12:12
Module start 'layout'
Timing:	Jan 18 2025 16:12:12
Module start 'content'
Timing:	Jan 18 2025 16:12:13
Module end 'content'
Timing:	Jan 18 2025 16:12:13
Script end

Main resources:

Total runtime	0.7444 sec
Peak memory usage	4,096.0000 KB
Database Queries	57

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0051	589.2734	152.6563
Module start 'layout'	0.0051	0.0027	741.9297	39.5078
Module start 'content'	0.0078	0.7352	781.4375	533.2969
Module end 'content'	0.7430	0.0014	1,314.7344	12.0938
Script end	0.7444		1,326.8281

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0034	0.4558	16	0.0002
Check MTime	0.0014	0.1880	16	0.0001
Mysql Total
Database connection	0.0008	0.1107	1	0.0008
Mysqli_queries	0.6994	93.9525	57	0.0123
Looping result	0.0005	0.0692	55	0.0000
Template Total	0.7133	95.8	2	0.3566
Template load	0.0020	0.2693	2	0.0010
Template processing	0.7113	95.5460	2	0.3556
Template load and register function	0.0002	0.0216	1	0.0002
states
state_id_array	0.0011	0.1418	1	0.0011
state_identifier_array	0.0018	0.2465	2	0.0009
Override
Cache load	0.0016	0.2187	17	0.0001
Sytem overhead
Fetch class attribute can translate value	0.0005	0.0642	2	0.0002
Fetch class attribute name	0.0011	0.1481	4	0.0003
XML
Image XML parsing	0.0006	0.0762	2	0.0003
class_abstraction
Instantiating content class attribute	0.0000	0.0009	4	0.0000
General
dbfile	0.0007	0.0988	16	0.0000
String conversion	0.0000	0.0011	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded
1	node/view/full.tpl	full/forum_topic.tpl	extension/sevenx/design/simple/override/templates/full/forum_topic.tpl
3	content/datatype/view/ezxmltext.tpl	<No override>	extension/community_design/design/suncana/templates/content/datatype/view/ezxmltext.tpl
5	content/datatype/view/ezxmltags/paragraph.tpl	<No override>	extension/ezwebin/design/ezwebin/templates/content/datatype/view/ezxmltags/paragraph.tpl
2	content/datatype/view/ezxmltags/line.tpl	<No override>	design/standard/templates/content/datatype/view/ezxmltags/line.tpl
1	content/datatype/view/ezimage.tpl	<No override>	extension/sevenx/design/simple/templates/content/datatype/view/ezimage.tpl
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 13 Number of unique templates used: 6

Time used to render debug report: 0.0001 secs