Mailing List Archive: Bricolage: users

Help with permissions

Index | Next | Previous | View Threaded

alex.loddengaard at redfin

Mar 17, 2008, 2:29 PM

Post #1 of 23 (1854 views)
Permalink

Help with permissions

I've been reading through the Security document
(http://www.bricolage.cc/docs/current/api/Bric/Security.html) in hopes
of learning about permissions, and I'm stuck. I'm trying to do the
following:

-I have two desks: edit and publish

-I have two user groups: contributors and publishers (not including all
the default "All *" groups)

-I have two users: A (a contributor) and B (a publisher)

-All other group areas are default and just have the "All *" group

-I want to setup my workflow such that a contributor can recall, create,
edit, and read the edit desk but only view the publish desk

First, is this possible? Second, if so, then how could I go about doing
it? I've done a lot of fiddling and I can't seem to figure this out. I
haven't been able to get user A to find an existing story or create a
new one.

Thanks in advance!

Alex

alex.loddengaard at redfin

Mar 17, 2008, 2:39 PM

Post #2 of 23 (1833 views)
Permalink

RE: Help with permissions [In reply to]

Apologizes for not keeping up with my list email - some of this was
answered in other threads. I do, however, not understand permissions
from a very fundamental level, so any/all help is greatly appreciated.

Thanks again!

Alex

-----Original Message-----
From: Alex Loddengaard [mailto:alex.loddengaard[at]redfin.com]
Sent: Monday, March 17, 2008 2:30 PM
To: users[at]lists.bricolage.cc
Subject: Help with permissions

I've been reading through the Security document
(http://www.bricolage.cc/docs/current/api/Bric/Security.html) in hopes
of learning about permissions, and I'm stuck. I'm trying to do the
following:

-I have two desks: edit and publish

-I have two user groups: contributors and publishers (not including all
the default "All *" groups)

-I have two users: A (a contributor) and B (a publisher)

-All other group areas are default and just have the "All *" group

-I want to setup my workflow such that a contributor can recall, create,
edit, and read the edit desk but only view the publish desk

First, is this possible? Second, if so, then how could I go about doing
it? I've done a lot of fiddling and I can't seem to figure this out. I
haven't been able to get user A to find an existing story or create a
new one.

Thanks in advance!

Alex

rolfm at denison

Mar 17, 2008, 6:49 PM

Post #3 of 23 (1839 views)
Permalink

Re: Help with permissions [In reply to]

Yeah, my recent thread should address that specifically. Maybe David
can share his hack!

In regards to understanding permissions - not sure where it was
posted, but at some point someone gave advice to read the security
page about 6 times - then come back and read it again. And then try
to implement what you want. And honestly, that's pretty good advice.

Keep searching this list - I think most arrangements have been tried
and questioned - I know I've done quite a few! And if have specific
questions the list doesn't address, then post them.

-Matt

On Mar 17, 2008, at 5:39 PM, Alex Loddengaard wrote:

> Apologizes for not keeping up with my list email - some of this was
> answered in other threads. I do, however, not understand permissions
> from a very fundamental level, so any/all help is greatly appreciated.
>
> Thanks again!
>
> Alex
>
> -----Original Message-----
> From: Alex Loddengaard [mailto:alex.loddengaard[at]redfin.com]
> Sent: Monday, March 17, 2008 2:30 PM
> To: users[at]lists.bricolage.cc
> Subject: Help with permissions
>
> I've been reading through the Security document
> (http://www.bricolage.cc/docs/current/api/Bric/Security.html) in hopes
> of learning about permissions, and I'm stuck. I'm trying to do the
> following:
>
>
>
> -I have two desks: edit and publish
>
> -I have two user groups: contributors and publishers (not including
> all
> the default "All *" groups)
>
> -I have two users: A (a contributor) and B (a publisher)
>
> -All other group areas are default and just have the "All *" group
>
> -I want to setup my workflow such that a contributor can recall,
> create,
> edit, and read the edit desk but only view the publish desk
>
>
>
> First, is this possible? Second, if so, then how could I go about
> doing
> it? I've done a lot of fiddling and I can't seem to figure this
> out. I
> haven't been able to get user A to find an existing story or create a
> new one.
>
>
>
> Thanks in advance!
>
> Alex
>
>
>
>

phillip at communitybandwidth

Mar 18, 2008, 8:31 AM

Post #4 of 23 (1838 views)
Permalink

Re: Help with permissions [In reply to]

On 17-Mar-08, at 5:29 PM, Alex Loddengaard wrote:
> First, is this possible? Second, if so, then how could I go about
> doing
> it? I've done a lot of fiddling and I can't seem to figure this
> out. I
> haven't been able to get user A to find an existing story or create a
> new one.

I think I just did this yesterday for an instance. Let me do it again
and capture the process... will post it shortly.

Phillip.

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca

david at kineticode

Mar 18, 2008, 3:18 PM

Post #5 of 23 (1836 views)
Permalink

Re: Help with permissions [In reply to]

On Mar 17, 2008, at 18:49, Matt Rolf wrote:

> In regards to understanding permissions - not sure where it was
> posted, but at some point someone gave advice to read the security
> page about 6 times - then come back and read it again. And then
> try to implement what you want. And honestly, that's pretty good
> advice.

I always suggest that, because it's what I have to do to re-learn the
system whenever I'm doing an implementation.

Best,

David

phillip at communitybandwidth

Apr 2, 2008, 8:40 AM

Post #6 of 23 (1809 views)
Permalink

Re: Help with permissions [In reply to]

On 18-Mar-08, at 11:31 AM, Phillip Smith wrote:
>
> On 17-Mar-08, at 5:29 PM, Alex Loddengaard wrote:
>> First, is this possible? Second, if so, then how could I go about
>> doing
>> it? I've done a lot of fiddling and I can't seem to figure this
>> out. I
>> haven't been able to get user A to find an existing story or create a
>> new one.
>
> I think I just did this yesterday for an instance. Let me do it
> again and capture the process... will post it shortly.

Hi ho,

Thanks to a little bump from Alex Loddengaard, I've put together a
little two-part screen cast on Bricolage permissions 101. I've also
started a Wiki page to document the steps here: http://wiki.bricolage.cc/bin/view/Bric/PermissionsOneOhOne

If anyone has other common scenarios for setting up basic permissions
to categories, or groups, let me know and I'll see if I can write them
up and turn them into screen casts. Or, better yet, try it
yourself! :-)

Part I (5 minutes):
http://screencast.com/t/G6s9goLNJ

Part II (5 minutes):
http://screencast.com/t/UPxGOSej

Just did these quickly, so apologies for the mumbling. No script to
read off of! :-)

Best,

Phillip.

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca

david at kineticode

Apr 2, 2008, 9:35 AM

Post #7 of 23 (1812 views)
Permalink

Re: Help with permissions [In reply to]

On Apr 2, 2008, at 08:40, Phillip Smith wrote:

> Thanks to a little bump from Alex Loddengaard, I've put together a
> little two-part screen cast on Bricolage permissions 101. I've also
> started a Wiki page to document the steps here: http://wiki.bricolage.cc/bin/view/Bric/PermissionsOneOhOne

You should link to the screencasts from there.

> If anyone has other common scenarios for setting up basic
> permissions to categories, or groups, let me know and I'll see if I
> can write them up and turn them into screen casts. Or, better yet,
> try it yourself! :-)
>
> Part I (5 minutes):
> http://screencast.com/t/G6s9goLNJ
>
> Part II (5 minutes):
> http://screencast.com/t/UPxGOSej
>
> Just did these quickly, so apologies for the mumbling. No script to
> read off of! :-)

Phillip, these are awesome. Looking at these, I get the impression that:

* You really know your shit about Bricolage. That's nice to see,
because most of the time when I do trainings and whatnot, folks
don't know much about it, and they never do learn much.
* Bricolage is fast! I never thought that before.
* Bricolage is easy to use.
* Bricolage can be fun.

Nicely done! I would even say we should link to the screencasts in
Bric::Security.

Thanks for making the effort on this stuff, it makes a huge difference.

Best,

David

phillip at communitybandwidth

Apr 3, 2008, 4:55 AM

Post #8 of 23 (1791 views)
Permalink

Re: Help with permissions [In reply to]

On 2-Apr-08, at 12:35 PM, David E. Wheeler wrote:
> On Apr 2, 2008, at 08:40, Phillip Smith wrote:
>
>> Thanks to a little bump from Alex Loddengaard, I've put together a
>> little two-part screen cast on Bricolage permissions 101. I've also
>> started a Wiki page to document the steps here:http://wiki.bricolage.cc/bin/view/Bric/PermissionsOneOhOne
>
> You should link to the screencasts from there.

Good idea and done.

I've also typed up a slightly longer version of the whole thing here: http://tinyurl.com/333mma

> Looking at these, I get the impression that:
>
> * You really know your shit about Bricolage.

I'm an impostor, I swear. Just good on camera. :-)

> * Bricolage is fast! I never thought that before.

It sure is. And, that's not even a local copy.

> * Bricolage can be fun.

To quote Bret: Bricolage is a box of magic crayons.

> Thanks for making the effort on this stuff, it makes a huge
> difference.

It Takes a Village ;-)

Thanks David! Over and out.

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca

chris.schults at pccsea

Apr 16, 2008, 11:48 AM

Post #9 of 23 (1716 views)
Permalink

RE: Help with permissions [In reply to]

> I've also typed up a slightly longer version of the whole thing here:
> http://tinyurl.com/333mma

Phillip, this is awesome. I needed to do basically the same thing as
your blogger example except for HR and job postings, and thanks to your
videos it was a piece of cake!

However, while creating new stories works as advertised, my HR user can
access and edit existing stories in other categories and of other types.
Though, it can only associate a story with the jobs category.

Is this the expected behavior?

FYI: Under workflow perms, the HR user has EDIT privileges for the Story
group. Under desk perms, it has the same privileges as a standard story
editor.

Chris

--------------------------------

Chris Schults
Web Developer
PCC Natural Markets
206-547-1222 x104
chris.schults[at]pccsea.com
http://www.pccnaturalmarkets.com

phillip at communitybandwidth

Apr 17, 2008, 12:31 PM

Post #10 of 23 (1712 views)
Permalink

Re: Help with permissions [In reply to]

Hey there Mr. Chris,

Just seeing this now. Stuck in meetings most of today -- but will give
this a noodle and respond asap. :-)

On 16-Apr-08, at 2:48 PM, Schults, Chris wrote:
>> I've also typed up a slightly longer version of the whole thing here:
>> http://tinyurl.com/333mma
>
> Phillip, this is awesome. I needed to do basically the same thing as
> your blogger example except for HR and job postings, and thanks to
> your
> videos it was a piece of cake!
>
> However, while creating new stories works as advertised, my HR user
> can
> access and edit existing stories in other categories and of other
> types.
> Though, it can only associate a story with the jobs category.
>
> Is this the expected behavior?
>
> FYI: Under workflow perms, the HR user has EDIT privileges for the
> Story
> group. Under desk perms, it has the same privileges as a standard
> story
> editor.
>
> Chris
>
>
> --------------------------------
>
> Chris Schults
> Web Developer
> PCC Natural Markets
> 206-547-1222 x104
> chris.schults[at]pccsea.com
> http://www.pccnaturalmarkets.com
>
>

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca

Don't miss the Social Tech Training:
www.marsdd.com/socialtechtraining
June 22-24, 2008 in Toronto

phillip at communitybandwidth

Apr 21, 2008, 4:01 PM

Post #11 of 23 (1677 views)
Permalink

Re: Help with permissions [In reply to]

On 16-Apr-08, at 2:48 PM, Schults, Chris wrote:
>> I've also typed up a slightly longer version of the whole thing here:
>> http://tinyurl.com/333mma
>
> Phillip, this is awesome. I needed to do basically the same thing as
> your blogger example except for HR and job postings, and thanks to
> your
> videos it was a piece of cake!
>
> However, while creating new stories works as advertised, my HR user
> can
> access and edit existing stories in other categories and of other
> types.
> Though, it can only associate a story with the jobs category.
>
> Is this the expected behavior?
>
> FYI: Under workflow perms, the HR user has EDIT privileges for the
> Story
> group. Under desk perms, it has the same privileges as a standard
> story
> editor.
>
> Chris

Sorry for the delay here Chris (and many thanks for kicking the tires!).

I was able to achieve what you're after by setting the "DEFAULT SITE
SITE CATEGORY PERMISSIONS" on / to DENY, while leaving it set to READ
on /blog/

I'll update that in my notes. Let me know if it works for you.

Best,

Phillip.

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth

chris.schults at pccsea

May 6, 2008, 3:33 PM

Post #12 of 23 (1539 views)
Permalink

RE: Help with permissions [In reply to]

> So, after closer review, it looks like my HR user only has access to
> other "non-approved" assets *only* when they are active. I assume it
is
> because they have the EDIT permission on the Story workflow and
> EDIT/CREATE/PUBLISH on Story desks -- the most permissive rule wins.
>
> As you suggested, I can change a category permission to DENY, but it
> appears I'd have to do this for every category (at least those used by
> story assets), and I still have a lot more to add.
>
> Is there a better way, or do I have to make it part of the process to
> adjust perms whenever a new category is added?

After sending the above, I realized that instead of restricting all but
one category (many), I could restrict by story type (far fewer). So, I
created an Element Type Group for each story type. And for the Human
Resources (User) Group, I changed the permission to DENY for all except
the story type Job.

However, after saving these changes, I discovered that my HR user can
still edit active stories even when their permission for that story type
is set to DENY. I thought DENY always overrides other perms -- is this
is a bug?

Chris

--------------------------------

Chris Schults
Web Developer
PCC Natural Markets
206-547-1222 x104
chris.schults[at]pccsea.com
http://www.pccnaturalmarkets.com

Sign up for PCC Fresh, a monthly newsletter filled with seasonal
recipes, exciting new products, and more:
http://www.pccnaturalmarkets.com/enews

david at kineticode

May 7, 2008, 10:27 AM

Post #13 of 23 (1512 views)
Permalink

Re: Help with permissions [In reply to]

On May 6, 2008, at 15:33, Schults, Chris wrote:

> After sending the above, I realized that instead of restricting all
> but
> one category (many), I could restrict by story type (far fewer). So, I
> created an Element Type Group for each story type. And for the Human
> Resources (User) Group, I changed the permission to DENY for all
> except
> the story type Job.
>
> However, after saving these changes, I discovered that my HR user can
> still edit active stories even when their permission for that story
> type
> is set to DENY. I thought DENY always overrides other perms -- is this
> is a bug?

Yeah, FBOFW, story types are not story groups. So you've limited your
HR user's access to story types, which she should not have been able
to edit anyway. You had no effect on stories.

The only types of groups that affect document/template permissions are:

* Story/Media/Template groups. Almost no one uses these, as it'd be
hard to keep objects in them.
* Workflows.
* Desks.
* Categories. At least with these, they inherit their permissions
from parent categories.

Best,

David

chris.schults at pccsea

May 7, 2008, 11:06 AM

Post #14 of 23 (1511 views)
Permalink

RE: Help with permissions [In reply to]

> Yeah, FBOFW, story types are not story groups. So you've limited your
> HR user's access to story types, which she should not have been able
> to edit anyway. You had no effect on stories.

Ah, thanks for the clarification. However, these Element Type Groups do
seem to limit what story types are available during story creation,
which is important.

> The only types of groups that affect document/template permissions
are:
>
> * Story/Media/Template groups. Almost no one uses these, as it'd be
> hard to keep objects in them.
> * Workflows.
> * Desks.
> * Categories. At least with these, they inherit their permissions
> from parent categories.

So, if my HR user has access to the same desks as everyone else, they'll
be able to edit any asset on those desks, unless restricted by another
permission, such as category. This does work, but as I said previously,
I would prefer not to have to update User Group permissions each time a
new category is added.

I did try restricting by parent category (as suggested above), but this
doesn't seem to work. For example, I changed the permission for
/community/ to DENY, but my user can access active assets in
/community/events/ and /community/kids/.

> Best,
>
> David

david at kineticode

May 7, 2008, 11:28 AM

Post #15 of 23 (1505 views)
Permalink

Re: Help with permissions [In reply to]

On May 7, 2008, at 11:06, Schults, Chris wrote:

> Ah, thanks for the clarification. However, these Element Type Groups
> do
> seem to limit what story types are available during story creation,
> which is important.

Yes, that's right, I'm sorry. A user has to be able to see individual
element types in order to create documents of those types or add
subelements of those types to documents. The same applies to
categories, IIRC.

> So, if my HR user has access to the same desks as everyone else,
> they'll
> be able to edit any asset on those desks, unless restricted by another
> permission, such as category.

Well, if she only has READ access to those desks, she won't be able to
edit them.

> This does work, but as I said previously,
> I would prefer not to have to update User Group permissions each
> time a
> new category is added.

Yeah, it sucks.

> I did try restricting by parent category (as suggested above), but
> this
> doesn't seem to work. For example, I changed the permission for
> /community/ to DENY, but my user can access active assets in
> /community/events/ and /community/kids/.

Once you've set the permission for a category, any *new* subcategories
of that category will inherit its permissions. Existing categories
will not be changed.

Best,

David

lannings at who

May 8, 2008, 4:49 AM

Post #16 of 23 (1498 views)
Permalink

Re: Help with permissions [In reply to]

On Wed, 7 May 2008, David E. Wheeler wrote:
> Yeah, it sucks.

How do other CMSs deal with permissions?
(general question, not necessarily only for David)

bret at pectopah

May 8, 2008, 10:10 AM

Post #17 of 23 (1490 views)
Permalink

Re: Help with permissions [In reply to]

Whoops. Accidentally sent this just to Scott. Sorry, Scott!

I think I'd hesitate to say it sucks. I really like permissions in
Bricolage.

Greg and I have been working with a totally different platform over the
past few month, a portal called Liferay, and its permissions system
reminds me a lot of several other systems.

You have a small basket of permissions ("view," "edit," "configure," and
so on), and you assign them to assets (individual articles, or users, or
groups of users, etc.), and you can create clusters of permissions
called "roles."

Basically it looks flexible as all get-out, but in practice it's just a
few tasks and a few kinds of assets.

Bricolage, on the other hand, actually takes its permissions approach
right down into the guts of the system, so you can map permissions onto
individual element types and individual categories. In Liferay's
built-in CMS (and in several others) that's just not possible at all, at
least without tons of source hacking.

Bricolage just has this built-in flexibility that comes to feel like
second nature when you're working with it closely. It's easy to forget
how amazing it is until you use another platform for a while.

Anyway, let me pipe up and say I also like story groups and template
groups for permissions. I've used them so that certain users can only
edit a set of pre-determined stories. They're amazing.

One problem, which I am personally determined to be the one to fix, is
that assigning stories to story groups gets a little browser-crashy when
you have tons of stories in your system. The UI uses two multiple-select
boxes to show available stories and selected ones, and when you have
nearly 70,000 stories in the system, as Sportsnet now does, the box on
the left can really make Firefox queasy.

Maybe implementing something like the category browser for groups would
be a good idea. Like I said, I'm determined to be the one...

Cheers,

Bret

On Thu, 2008-05-08 at 13:49 +0200, Scott Lanning wrote:
> On Wed, 7 May 2008, David E. Wheeler wrote:
> > Yeah, it sucks.
>
> How do other CMSs deal with permissions?
> (general question, not necessarily only for David)
>
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret[at]pectopah.com
www.pectopah.com

david at kineticode

May 8, 2008, 10:18 AM

Post #18 of 23 (1489 views)
Permalink

Re: Help with permissions [In reply to]

On May 8, 2008, at 10:10, Bret Dawson wrote:

> I think I'd hesitate to say it sucks. I really like permissions in
> Bricolage.

They're an excellent 80% solution.

> Bricolage just has this built-in flexibility that comes to feel like
> second nature when you're working with it closely. It's easy to forget
> how amazing it is until you use another platform for a while.

It's complex, but pretty comprehensive. So, yeah, it can be a bitch to
learn, and there are certain things it can't do, but once you get used
to it, there is indeed a lot it can do.

> Anyway, let me pipe up and say I also like story groups and template
> groups for permissions. I've used them so that certain users can only
> edit a set of pre-determined stories. They're amazing.

Nice, that's just what they were intended for. I didn't know anyone
was actually using them that way.

> One problem, which I am personally determined to be the one to fix, is
> that assigning stories to story groups gets a little browser-crashy
> when
> you have tons of stories in your system. The UI uses two multiple-
> select
> boxes to show available stories and selected ones, and when you have
> nearly 70,000 stories in the system, as Sportsnet now does, the box on
> the left can really make Firefox queasy.
>
> Maybe implementing something like the category browser for groups
> would
> be a good idea. Like I said, I'm determined to be the one...

I think that's a good idea. We can code which interface to use, double
list or browser, based on the type of object. So for stories and media
you'd use the search widget, while for most other things you'd use the
double list manager.

All this reminds me: I've had this on my to-do list for a long time,
and since I was away for a while, I've no idea what it means:

"Add Permission Group ID checking to Bricolage Trunk"

Does anyone know WTF I was talking about there?

Also, I think that it'd be reasonable to add support for grouping
stories and templates and media by top-level element types, so that
Chris could get what he was looking for. Anyone want to take that on?
It'd work similarly to how category permissions work when editing a
user group's permissions.

Best,

David

chris.schults at pccsea

May 8, 2008, 10:35 AM

Post #19 of 23 (1483 views)
Permalink

RE: Help with permissions [In reply to]

> I think I'd hesitate to say it sucks. I really like permissions in
> Bricolage.

I agree with Bret. What could be better is the documentation, which is why Phillip's video tutorials rock! Also, as David has mentioned, how one defines category permissions for user groups could be improved.

Chris

--------------------------------

Chris Schults
Web Developer
PCC Natural Markets
206-547-1222 x104
chris.schults[at]pccsea.com
http://www.pccnaturalmarkets.com

Sign up for PCC Fresh, a monthly newsletter filled with seasonal recipes, exciting new products, and more:
http://www.pccnaturalmarkets.com/enews

lannings at who

May 9, 2008, 12:51 AM

Post #20 of 23 (1481 views)
Permalink

RE: Help with permissions [In reply to]

On Thu, 8 May 2008, Schults, Chris wrote:
>> I think I'd hesitate to say it sucks. I really like permissions in
>> Bricolage.
>
> I agree with Bret. What could be better is the documentation, which is why
> Phillip's video tutorials rock! Also, as David has mentioned, how one defines
> category permissions for user groups could be improved.

I agree that the problems are mainly just ones of improvement.
You'll set the permissions for an "object" within the system,
but the result of doing that is sometimes unintuitive,
because there's no real "hierarchy" of objects (no way to specify
which permissions of which objects depend on the others),
other than what someone felt like putting into a Mason component [1]
whenever they added a feature. For example, if I set READ permissions
on a Category object, I personally would expect that nothing
"belonging to" ("in", "under") that Category would be EDITable.

(As a possible corollary of the above, [2]
it should (possibly) be possible to specify not just a grouping of
permissions but a hierarchy of the objects with explicit rules for
how the permissions are inherited.)

[1] which is another problem: the permissions are sometimes
embedded in the UI, c.f. `grep -r chk_authz comp`
(or `grep -r chk_authz lib/Bric/SOAP/`),
rather than integrated into the API.

[2] and as a parenthetical note, since I'm not volunteering to implement
anything and I try to avoid suggesting things be done that I'm not
volunteering to do.

lannings at who

May 9, 2008, 1:15 AM

Post #21 of 23 (1480 views)
Permalink

Re: Help with permissions [In reply to]

On Wed, 7 May 2008, David E. Wheeler wrote:
> The only types of groups that affect document/template permissions are:
>
> * Story/Media/Template groups. Almost no one uses these, as it'd be hard
> to keep objects in them.
> * Workflows.
> * Desks.
> * Categories. At least with these, they inherit their permissions from
> parent categories.

Hmm, maybe I've misunderstood something or am out of date,
so my last message might not be...based on correct assumptions..

lannings at who

May 9, 2008, 1:20 AM

Post #22 of 23 (1483 views)
Permalink

Re: Help with permissions [In reply to]

On Wed, 7 May 2008, David E. Wheeler wrote:
> On May 7, 2008, at 11:06, Schults, Chris wrote:
>> I did try restricting by parent category (as suggested above), but this
>> doesn't seem to work. For example, I changed the permission for
>> /community/ to DENY, but my user can access active assets in
>> /community/events/ and /community/kids/.
>
> Once you've set the permission for a category, any *new* subcategories of
> that category will inherit its permissions. Existing categories will not be
> changed.

Oh.... uh, nevermind....

david at kineticode

May 9, 2008, 9:25 AM

Post #23 of 23 (1473 views)
Permalink

Re: Help with permissions [In reply to]

On May 9, 2008, at 00:51, Scott Lanning wrote:

> (As a possible corollary of the above, [2]
> it should (possibly) be possible to specify not just a grouping of
> permissions but a hierarchy of the objects with explicit rules for
> how the permissions are inherited.)

Don't really follow you here.

> [1] which is another problem: the permissions are sometimes
> embedded in the UI, c.f. `grep -r chk_authz comp`
> (or `grep -r chk_authz lib/Bric/SOAP/`),
> rather than integrated into the API.

Yes. Wasn't my idea, though the implementation is mine. Sorry folks.
My insistence that Christian put the enforcement of occurrence
specifications into the API, BTW, made integrating it into the rest of
the app easy. It pretty much just worked.

Best,

David

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com