Help with permissions

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

You're welcome Phillip. Sorry I haven't replied sooner, but
I'm just
getting back to this.

> 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.

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?

Chris


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

Chris Schults
Web Developer
PCC Natural Markets
206-547-1222 x104
chris.schultspccsea.com
http://www.pccnatura
lmarkets.com

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

> 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.schultspccsea.com
http://www.pccnatura
lmarkets.com

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

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

> 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

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

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)

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
bretpectopah.com
www.pectopah.com

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

> 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.schultspccsea.com
http://www.pccnatura
lmarkets.com

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

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.