More Permissions Fun - Desks & Recall

We have some Desks in a workflow.  Our editors can

Desk 1 - RECALL
Desk 2 - READ
Desk 3 - NONE
Desk 4 - NONE

There is also a category group.

If the category group is set to READ, then Editors can not
check out  
any recalled stories that are not in a workflow, but they
can edit  
them on Desk 1.  They can not edit stories on Desk #2.

If the category group is set to RECALL, then editors can
check out  
recalled stories, but they can also edit them on Desk 2.

That doesn't seem right. Any insights?

-Matt

Hi Matt.

I think this is a consequence of a general rule: the most
permissive
permission wins.

So if users have RECALL permission on stories in a category,
they get to
edit those stories pretty much any place. If those stories
happen to be
on a desk they can see (that is, have READ access on), they
will be able
to edit those stories, because the RECALL on the category
group is more
permissive than the READ on the desk.

In general, I find desk permissions most useful for fairly
linear
workflows, where somebody starts a publish process and then
moves the
story to another desk, and the people who work with it on
that desk
never do any recalling or creating, they just work with what
arrives
there.

Category permissions, on the other hand, are best for
situations where
different groups of users have sovereignty over different
chunks of the
site. For example, you might have PR people who work with
press
releases, and they might have free reign to
create/recall/publish in
the /pr/ category, but not have any access to other
categories.

I hope this makes sense. Long story short, what you're
seeing is
expected behaviour.


Best,

Bret

On Fri, 2008-03-14 at 10:20 -0400, Matt Rolf wrote:
> We have some Desks in a workflow.  Our editors can
> 
> Desk 1 - RECALL
> Desk 2 - READ
> Desk 3 - NONE
> Desk 4 - NONE
> 
> There is also a category group.
> 
> If the category group is set to READ, then Editors can
not check out  
> any recalled stories that are not in a workflow, but
they can edit  
> them on Desk 1.  They can not edit stories on Desk #2.
> 
> If the category group is set to RECALL, then editors
can check out  
> recalled stories, but they can also edit them on Desk
2.
> 
> That doesn't seem right. Any insights?
> 
> -Matt
> 
-- 
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bretpectopah.com
www.pectopah.com

On Mar 14, 2008, at 07:40, Bret Dawson wrote:

> I think this is a consequence of a general rule: the
most permissive
> permission wins.
>
> So if users have RECALL permission on stories in a
category, they  
> get to
> edit those stories pretty much any place. If those
stories happen to  
> be
> on a desk they can see (that is, have READ access on),
they will be  
> able
> to edit those stories, because the RECALL on the
category group is  
> more
> permissive than the READ on the desk.
>
> In general, I find desk permissions most useful for
fairly linear
> workflows, where somebody starts a publish process and
then moves the
> story to another desk, and the people who work with it
on that desk
> never do any recalling or creating, they just work with
what arrives
> there.
>
> Category permissions, on the other hand, are best for
situations where
> different groups of users have sovereignty over
different chunks of  
> the
> site. For example, you might have PR people who work
with press
> releases, and they might have free reign to
create/recall/publish in
> the /pr/ category, but not have any access to other
categories.
>
> I hope this makes sense. Long story short, what you're
seeing is
> expected behaviour.

Terrific explanation, Bret, thanks!

Has anyone started a permissions wiki page? Stuff like this
should go  
on it.

Best,

David
(Who is mindful of the redfin blog post about Bricolage
documentation  
being all over the place.)

>
>
> Has anyone started a permissions wiki page? Stuff like
this should  
> go on it.
>
> Best,
>
> David
> (Who is mindful of the redfin blog post about Bricolage
 
> documentation being all over the place.)


It sure is all over the place. I've been thinking about how
to pull it  
all together this weekend. I'm starting to think that all
wiki  
documentation (template and otherwise) should be a part of
the same  
wiki - simply because it's all interrelated. (You can
checkout the http://buildingbrics.com

  home page to see how I think the documentation could be
handled in  
this area - https://www.buildingbrics.com/trac/wiki/TemplateConcept
s.  
This directory could link to description pages for
individual  
templates - https://www.buildingbrics.com/trac/wiki/TemplateDirect
ory.  
Certain templates could be tagged with a general concept
keyword if  
they help illustrate a Templating concept  outlined in / 
TemplateConcept.)

As well I find the way documentation is categorized on the 

bricolage.cc site rather confusing (although there is much I
like  
about the crisp design of the site). I think we should
divide up  
documentation for various user groups:

- End Users (Matt and crew started doing that on their
school site)
- Templators (With reference and links to the useful bits in
the API  
docs)
- System Admins (The people who set up the bricolage
installs )
- Developers (People who develop Bricolage, fix bugs, check
out from  
subversion) - would you also call them Hackers?
- Integration Workers (People who need to make another
program play  
nicely with Bricolage)

It seems to me our Documentation > HowTos section of the
site http://bricolage.cc/
docs/howtos/ 
  only offers 4 articles and they mix up the user categories
I define  
above, which could leave a new user feeling pretty
frustrated if she's  
new to the system.

  In other words, the person who needs to know 'How to
Include Images  
in Your Stories' probably isn't concerned with 'How to run
Bricolage  
on a Virtual Host and on Non-Standard Ports' since she
probably  
already got someone to set it up for her and is starting to
build  
templates or use the default ones in the system.  However
she might be  
interested in 'How to Use Bricolage Workflows' and maybe
something  
called 'How to Publish your first story'.

As well I think many people new to the bricolage.cc site may
miss that  
there is a direct link to this Documentation start page http://bricolage.cc/docs/ 
  . If breadcrumb nav was added to the site it might be more
apparent  
that there is a 'home' for documentation (the right sidebar
is not  
contextual and only shows 'news' items).

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

The articles that I think really should be in one place and
linked  
together are (these have been mentioned in Chris' Templates
101 list):

For Templators:
- Advanced Templates http://bricolage.cc/docs/current/api/?Bric::AdvTemplates

- Element Admin http://bricolage.cc/docs/current/api/?Bric::ElementAdmin

         companion piece:
     -   'Document Modeling with Bricolage' http://www.perl.com/pub/a/2005/11/23/bricolage_analy
sis.html

- 'Priv' - http://bricolage.cc/docs/current/api/?Bric::Util::Priv

   companion piece:
    -  'How to Use Workflows' 
http://bricolage.cc/docs/howtos/2004/12/23/workflow/)

For System Admins:
- htt
p://bricolage.cc/docs/current/api/?Bric::Admin
     companion pieces:
   - 'Bricolage Configuration Directives' http://www.perl.com/pub/a/2005/01/06/bricolage_
configuration.html
   - 'Bricolage Installation' - http://www.perl.com/pub/a/2004/10/28/bricolage_i
nstallation.html
   - 'Installation Tips' - http://wiki.bricolage.cc/bin/view/Bric/InstallationTips
   - Using VMWare to install Bricolage - 
http://bricolage.cc/news/announce/2007/10/01/vmware/


For New Users or Organizations Considering Bricolage:
- 'Content Management with Bricolage' h
ttp://www.perl.com/pub/a/2004/08/27/bricolage.html
- 'Discovering Bricolage' PDF - http://www.kineticode.com/docs/discovering_bricolage.pdf


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

I'm also wondering if most of the documentation should be in
the  
wiki(s) rather than the bricolage.cc site. If there is a bit
of both  
in both places I wonder how it should be divided.

I'm also wondering if David's articles which are on perl.com
could be  
copied to the site/wiki and updated slightly with newer
screen shots.  
Bret added screenshots http://bricolag
e.cc/docs/screenshots/ but I'd  
like to see them connected to documentation on these areas
of Bricolage.

I think the FAQ is pretty good http://bricolage.cc/doc
s/faq/  but I'd  
like to see that similarly divided up for different kinds of
users.

I also think bits from the API that people use frequently in
their  
templates should be pulled out into a 'cheat sheet', for
instance all  
the $story->list()methods. And all the ways you can
format Dates etc  
also deserve a wiki page and Article/Tutorial.

There are also many excellent explanations that have been
written up  
in the mailing lists over the years and I think these could
be pulled  
as FAQs or as Tutorial on their own.

Feedback?

Dawn

On 16-Mar-08, at 12:08 AM, Dawn Buie wrote:

> It sure is all over the place. I've been thinking about
how to pull  
> it all together this weekend. I'm starting to think
that all wiki  
> documentation (template and otherwise) should be a part
of the same  
> wiki - simply because it's all interrelated.

Agreed and nice work on pushing it in that direction.  

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

On Mar 14, 2008, at 10:40 AM, Bret Dawson wrote:

> Hi Matt.
>
> I think this is a consequence of a general rule: the
most permissive
> permission wins.
>
> So if users have RECALL permission on stories in a
category, they  
> get to
> edit those stories pretty much any place. If those
stories happen to  
> be
> on a desk they can see (that is, have READ access on),
they will be  
> able
> to edit those stories, because the RECALL on the
category group is  
> more
> permissive than the READ on the desk.
>
> In general, I find desk permissions most useful for
fairly linear
> workflows, where somebody starts a publish process and
then moves the
> story to another desk, and the people who work with it
on that desk
> never do any recalling or creating, they just work with
what arrives
> there.
>
> Category permissions, on the other hand, are best for
situations where
> different groups of users have sovereignty over
different chunks of  
> the
> site. For example, you might have PR people who work
with press
> releases, and they might have free reign to
create/recall/publish in
> the /pr/ category, but not have any access to other
categories.


But we have both - they only need to be able to edit
documents in a  
certain category and on a certain desk.

I'm also confused as to how people are allowed to edit pages
without  
category permission.  Is it even possible if someone doesn't
have  
recall permission on a category?

-Matt

On Mar 15, 2008, at 21:08, Dawn Buie wrote:

> It sure is all over the place. I've been thinking about
how to pull  
> it all together this weekend.

+1 on your suggestions.

Best,

David

On Mar 16, 2008, at 12:08 AM, Dawn Buie wrote:
>
> Feedback?

THere was a discussion on this topic on the dev list when
you were  
missing.  You might want to read through it if you haven't
yet.

-Matt