Mailing List Archive

Hi Aaron,

I don't think there's a way to do what you want all at once (or if there
is, I haven't managed it).

Crazy as it sounds, your best bet might be to do it with an external
script (or even an ad-hoc utility template). The Bricolage API itself is
good at manipulating categories, so you could look up the categories
that are in your target groups, and then change their permissions in a
loop.

David is probably about to point a brilliantly easy solution, though, so
you might want to hold off for a moment...


Hope this helps,

Bret


On Tue, 2009-10-20 at 16:35 -0400, Aaron Fuleki wrote:
> Let's say you have a user group and a category group, and you want to
> grant PUBLISH privileges on all the categories in your category group
> to all the members of the user group.
>
> If you go to the Site Category Permissions for the user group, you can
> choose from the full NONE/READ/EDIT/RECALL/PUBLISH/DENY privileges for
> individual categories. This works, but is tedious and brittle
> (category additions/removals require remembering to update all the
> groups who need access).
>
> Under the user group's Object Group Permission section, you call also
> choose from the full NONE/READ/EDIT/RECALL/PUBLISH/DENY privileges for
> the "All Categories" group. This works for admin-level user groups,
> but not for groups that need, say PUBLISH access on many, but not all
> categories.
>
> The only privilege options that you can grant a user group to a
> category group are NONE/READ/EDIT/DENY. I assume this gives members
> of the user group privileges to READ or EDIT which categories are
> members of the category group.
>
> It seems like there are two types of privileges you'd want to assign
> to a category group: what a user group is allowed to the category
> group itself (add/remove categories, which I think is the current
> behavior), and what a user group is allowed to do with assets in those
> categories (READ/EDIT/RECALL/CREATE/PUBLISH - what I'm trying to do).
>
> How can you grant a user group, say, PUBLISH privileges on all the
> member categories of a category group, without manually setting the
> category permissions for each individual category?
>
> -Aaron
>
>
> ---------------------------------
> Aaron Fuleki
> Senior Web Architect
> Denison University
> 740.587.5752
> ---------------------------------
>
>
>
>
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

On 21-Oct-09, at 2:13 PM, David E. Wheeler wrote:

> On Oct 20, 2009, at 1:35 PM, Aaron Fuleki wrote:
>
>> The only privilege options that you can grant a user group to a
>> category group are NONE/READ/EDIT/DENY. I assume this gives
>> members of the user group privileges to READ or EDIT which
>> categories are members of the category group.
>
> And the ability to READ and EDIT the category itself in the ADMIN
> section.
>
>> It seems like there are two types of privileges you'd want to
>> assign to a category group: what a user group is allowed to the
>> category group itself (add/remove categories, which I think is the
>> current behavior), and what a user group is allowed to do with
>> assets in those categories (READ/EDIT/RECALL/CREATE/PUBLISH - what
>> I'm trying to do).
>
> Correct.
>
>> How can you grant a user group, say, PUBLISH privileges on all the
>> member categories of a category group, without manually setting the
>> category permissions for each individual category?
>
> Unfortunately, you don't. You can grant PUBLISH permissions to
> individual categories in the (Story|Media|Template) Group
> Permissions screen. The thing is to think of categories as groups of
> assets, and you can only grant PUBLISH to asset groups.
>
> You'll want to grant READ permission to your category group, though,
> so that your users can add categories to a story. Gotta be able to
> see them to add them.
>
> HTH,
>
> David

I've not read this thread thoroughly enough to know if they would be
helpful in the scenario you are describing, but there are a couple of
permissions 101 screencasts here: http://www.communitybandwidth.ca/phillipadsmith/bricolage-permissions-101

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On Oct 20, 2009, at 1:35 PM, Aaron Fuleki wrote:

> The only privilege options that you can grant a user group to a
> category group are NONE/READ/EDIT/DENY. I assume this gives members
> of the user group privileges to READ or EDIT which categories are
> members of the category group.

And the ability to READ and EDIT the category itself in the ADMIN
section.

> It seems like there are two types of privileges you'd want to assign
> to a category group: what a user group is allowed to the category
> group itself (add/remove categories, which I think is the current
> behavior), and what a user group is allowed to do with assets in
> those categories (READ/EDIT/RECALL/CREATE/PUBLISH - what I'm trying
> to do).

Correct.

> How can you grant a user group, say, PUBLISH privileges on all the
> member categories of a category group, without manually setting the
> category permissions for each individual category?

Unfortunately, you don't. You can grant PUBLISH permissions to
individual categories in the (Story|Media|Template) Group Permissions
screen. The thing is to think of categories as groups of assets, and
you can only grant PUBLISH to asset groups.

You'll want to grant READ permission to your category group, though,
so that your users can add categories to a story. Gotta be able to see
them to add them.

HTH,

David

On Oct 21, 2009, at 8:49 AM, Phillip Smith wrote:

> I've not read this thread thoroughly enough to know if they would be
> helpful in the scenario you are describing, but there are a couple
> of permissions 101 screencasts here:http://www.communitybandwidth.ca/
> phillipadsmith/bricolage-permissions-101

I also forgot to mention that if you create a new category, it will by
default inherit the permissions granted to the parent. This is to
cover the 90% of the time when they *should* be the same.

HTH,

David

Sorry to be late with this, but I wanted to add in my 2 cents and it
took some time to jell.

For those not familiar with the Denison permissions setup as it
currently stands, each subsite has two groups of users - maintainers
and approvers. Both sets of users can do anything, including create
pages, except maintainers can not publish. Users are added or removed
to the appropriate subsite groups, and new groups are created with new
subsites. In this way, you can achieve a pretty good level of
granularity and control over what users have access to while not
having to manage new permissions every day.

This model starts to break down when later on you want to add a new
group that can, say, just have recall privileges over pages in the
Academic section. If you've never created a group with a set of just
"recall" privileges over the Academics category or subsites within
it, and now there are 10s of categories under it, not to mention
desks, you can't just create a group in the UI and give it permissions
over all the categories below it - if I recall correctly, you need to
go flip the switch on every subcategory that exists. And the same
thing with desks, as the Denison bug report from last week described.

So what can be done? It looks like right now all Denison can do is
create new subsite groups with recall permission, have a student
propagate those permissions to the subsites (by hand, no less), and
then they could create group groups for the aggregated permissions
(Academics or Offices) like they want. Denison *can* get to what it
wants to do - it just has to go back and remedy an omission in the
original setup at the cost of 40 hours of student time.

And I think Aaron and Mike's complaint is, perhaps rightfully, that's
time consuming and we shouldn't have to do all that work. There
should be a switch that we flip that lets us set up a permissions
group at a top level category and have that cascade down to ones that
are already created. We shouldn't be expected to know every single
permissions group we're going to need when we fire this thing up,
because that's unreasonable. And if this is really an enterprise
class app, then it should have tools that let us manage these
permissions rapidly at a macro level.

But there's a trade off. Because Bricolage provides a level of
abstraction that allows fine control and almost total customization
over the creation of groups, it *doesn't* have a default permissions
model that it forces users to adopt. If the CMS were less abstract in
this regard, it might be easier to provide admin tools that do what
Aaron and Mike want - but Bricolage might lose some flexibility. I'm
not saying it can't happen, nor that what they're saying shouldn't get
fixed/added. But I am wondering out loud if the situation is partly
due to how the app itself is set up.

And my other question is, if they can do what they are asking, would
it not "break" the permissions model that they currently have. In
other words, would building things out as I suggest in fact be the
"right" way to go about things and actually give them even more
flexibility in the future than what they are proposing? I'll come out
and say it, I think the answer to that is yes.

I personally wouldn't describe the Bricolage permissions interface as
"tedious" or "brittle." On the other hand, "unforgiving of omissions
at site creation time?" Yeah, I think that is accurate. Had the
recall groups Aaron and Mike are on about been thought about and
created when the site was built out, I don't think this would be much
of an issue. But now we need a class of user with slightly different
set of restrictions, and having not known or thought of that when we
built out the site, well, here we are.

I'll take full responsibility for messing up since I was the one who
built that out, but I don't think it's much comfort to my former
colleagues.

-Matt


On Oct 20, 2009, at 4:35 PM, Aaron Fuleki wrote:

> If you go to the Site Category Permissions for the user group, you
> can choose from the full NONE/READ/EDIT/RECALL/PUBLISH/DENY
> privileges for individual categories. This works, but is tedious
> and brittle (category additions/removals require remembering to
> update all the groups who need access).
>
> Under the user group's Object Group Permission section, you call
> also choose from the full NONE/READ/EDIT/RECALL/PUBLISH/DENY
> privileges for the "All Categories" group. This works for admin-
> level user groups, but not for groups that need, say PUBLISH access
> on many, but not all categories.
>
> The only privilege options that you can grant a user group to a
> category group are NONE/READ/EDIT/DENY. I assume this gives members
> of the user group privileges to READ or EDIT which categories are
> members of the category group.
>
> It seems like there are two types of privileges you'd want to assign
> to a category group: what a user group is allowed to the category
> group itself (add/remove categories, which I think is the current
> behavior), and what a user group is allowed to do with assets in
> those categories (READ/EDIT/RECALL/CREATE/PUBLISH - what I'm trying
> to do).
>
> How can you grant a user group, say, PUBLISH privileges on all the
> member categories of a category group, without manually setting the
> category permissions for each individual category?
>
> -Aaron
>
>
> ---------------------------------
> Aaron Fuleki
> Senior Web Architect
> Denison University
> 740.587.5752
> ---------------------------------
>
>
>

I'm wondering if some kind of permissions API might help in this
regards, i.e., allowing some "programability" when setting up new
groups of permissions.

Phillip.

On 28-Oct-09, at 11:44 AM, Matt Rolf wrote:

> Sorry to be late with this, but I wanted to add in my 2 cents and it
> took some time to jell.
>
> For those not familiar with the Denison permissions setup as it
> currently stands, each subsite has two groups of users - maintainers
> and approvers. Both sets of users can do anything, including create
> pages, except maintainers can not publish. Users are added or
> removed to the appropriate subsite groups, and new groups are
> created with new subsites. In this way, you can achieve a pretty
> good level of granularity and control over what users have access
> to while not having to manage new permissions every day.
>
> This model starts to break down when later on you want to add a new
> group that can, say, just have recall privileges over pages in the
> Academic section. If you've never created a group with a set of
> just "recall" privileges over the Academics category or subsites
> within it, and now there are 10s of categories under it, not to
> mention desks, you can't just create a group in the UI and give it
> permissions over all the categories below it - if I recall
> correctly, you need to go flip the switch on every subcategory that
> exists. And the same thing with desks, as the Denison bug report
> from last week described.
>
> So what can be done? It looks like right now all Denison can do is
> create new subsite groups with recall permission, have a student
> propagate those permissions to the subsites (by hand, no less), and
> then they could create group groups for the aggregated permissions
> (Academics or Offices) like they want. Denison *can* get to what it
> wants to do - it just has to go back and remedy an omission in the
> original setup at the cost of 40 hours of student time.
>
> And I think Aaron and Mike's complaint is, perhaps rightfully,
> that's time consuming and we shouldn't have to do all that work.
> There should be a switch that we flip that lets us set up a
> permissions group at a top level category and have that cascade down
> to ones that are already created. We shouldn't be expected to know
> every single permissions group we're going to need when we fire this
> thing up, because that's unreasonable. And if this is really an
> enterprise class app, then it should have tools that let us manage
> these permissions rapidly at a macro level.
>
> But there's a trade off. Because Bricolage provides a level of
> abstraction that allows fine control and almost total customization
> over the creation of groups, it *doesn't* have a default permissions
> model that it forces users to adopt. If the CMS were less abstract
> in this regard, it might be easier to provide admin tools that do
> what Aaron and Mike want - but Bricolage might lose some
> flexibility. I'm not saying it can't happen, nor that what they're
> saying shouldn't get fixed/added. But I am wondering out loud if
> the situation is partly due to how the app itself is set up.
>
> And my other question is, if they can do what they are asking, would
> it not "break" the permissions model that they currently have. In
> other words, would building things out as I suggest in fact be the
> "right" way to go about things and actually give them even more
> flexibility in the future than what they are proposing? I'll come
> out and say it, I think the answer to that is yes.
>
> I personally wouldn't describe the Bricolage permissions interface
> as "tedious" or "brittle." On the other hand, "unforgiving of
> omissions at site creation time?" Yeah, I think that is accurate.
> Had the recall groups Aaron and Mike are on about been thought about
> and created when the site was built out, I don't think this would be
> much of an issue. But now we need a class of user with slightly
> different set of restrictions, and having not known or thought of
> that when we built out the site, well, here we are.
>
> I'll take full responsibility for messing up since I was the one who
> built that out, but I don't think it's much comfort to my former
> colleagues.
>
> -Matt
>
>
> On Oct 20, 2009, at 4:35 PM, Aaron Fuleki wrote:
>
>> If you go to the Site Category Permissions for the user group, you
>> can choose from the full NONE/READ/EDIT/RECALL/PUBLISH/DENY
>> privileges for individual categories. This works, but is tedious
>> and brittle (category additions/removals require remembering to
>> update all the groups who need access).
>>
>> Under the user group's Object Group Permission section, you call
>> also choose from the full NONE/READ/EDIT/RECALL/PUBLISH/DENY
>> privileges for the "All Categories" group. This works for admin-
>> level user groups, but not for groups that need, say PUBLISH access
>> on many, but not all categories.
>>
>> The only privilege options that you can grant a user group to a
>> category group are NONE/READ/EDIT/DENY. I assume this gives
>> members of the user group privileges to READ or EDIT which
>> categories are members of the category group.
>>
>> It seems like there are two types of privileges you'd want to
>> assign to a category group: what a user group is allowed to the
>> category group itself (add/remove categories, which I think is the
>> current behavior), and what a user group is allowed to do with
>> assets in those categories (READ/EDIT/RECALL/CREATE/PUBLISH - what
>> I'm trying to do).
>>
>> How can you grant a user group, say, PUBLISH privileges on all the
>> member categories of a category group, without manually setting the
>> category permissions for each individual category?
>>
>> -Aaron
>>
>>
>> ---------------------------------
>> Aaron Fuleki
>> Senior Web Architect
>> Denison University
>> 740.587.5752
>> ---------------------------------
>>
>>
>>
>

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com