List Info

Thread: Even more flexibility in content management




Even more flexibility in content management
user name
2006-12-28 21:23:30

(might arrive twice... excuse me if it does)


I was looking through Drupal.org to find if there is work towards granulating the permissions table a bit more, by adding a way to limit administer/access to nodes by type.
The idea (which has certainly been raised before) is to add, next to:

"create TYPE content",
- adding new nodes of that content type
"edit own TYPE content", - editing the contents of own nodes of that content type
"edit TYPE content", - editing the contents of all nodes of that content type (whether or not the user has right to create nodes)

two more possibilities:

"view TYPE content"
- roles that are allowed to view the content type's nodes
"administer TYPE content" - roles that are allowed to modify the publishing options on all nodes of that content type

I encounter more and more situations where I want to delegate the publishing options permission to a specific role, but only to one content type, otherwise I have to give the person control over the whole site's content.

Such a change should be done through core, so actually my questions are:
Is there any work on this direction / open issue?
Are there already any conclusions?
Should I start writing a patch ?

Cheers,
Zohar



--

Zohar Stolar   |   זהר סטולר
לינווייט תשתיות תוכן קהילתיות
Even more flexibility in content management
user name
2006-12-28 22:05:48


two more possibilities:

"view TYPE content"
- roles that are allowed to view the content type's nodes
"administer TYPE content" - roles that are allowed to modify the publishing options on all nodes of that content type

I think this is a good idea. +1 from me.

The problem now is that "access content" includes every type of content, regardless.
This prevents sites who want to make a certain content type premium, or just for registered users only, while the other types are still accessible.

(e.g. recruiters can view resumes, but other users cannot).

You need to check everywhere "access content" is used, and change that. Perhaps some contrib modules need to change as well.

Don't hold your breath on this getting in for 5.0 though. Looks perfect for 6.0.
Even more flexibility in content management
user name
2006-12-28 22:28:55
On Thursday 28 December 2006 3:23 pm, Zohar Stolar wrote:

>  I encounter more and more situations where I want to
delegate the
> publishing options permission to a specific role, but
only to one content
> type, otherwise I have to give the person control over
the whole site's
> content.
>
>  Such a change should be done through core, so actually
my questions are:
>  Is there any work on this direction / open issue?

Lots of separate patches that make permissions more
fine-grained in various 
areas, but no mega-patch that I know of.

>  Are there already any conclusions?

More-fine-grained-permission patches keep getting accepted,
so my conclusion 
is that it's an accepted direction to be moving.

>  Should I start writing a patch  ?

Yes! 

I've previously stated that there are 7 CRUD permissions:
Create, View, View 
Own, Edit, Edit Own, Delete, Delete Own.  With dynamic types
from node 
module, it should be quite feasible to provide that full set
to all 
node-module-based nodes for D6.  (Completely custom nodes
are largely on 
their own currently, and I'm not sure how to change that
other than leading 
by example.)

-- 
Larry Garfield			AIM: LOLG42
larrygarfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than
all others of 
exclusive property, it is the action of the thinking power
called an idea, 
which an individual may exclusively possess as long as he
keeps it to 
himself; but the moment it is divulged, it forces itself
into the possession 
of every one, and the receiver cannot dispossess himself of
it."  -- Thomas 
Jefferson
Even more flexibility in content management
user name
2006-12-28 22:43:10
Hi Zohar,

If you need need permissions that are more fine-grained than
the ones
available on the 'administer access control' page, your best
bet would
be to explore the node access system. Modules can implement
the node
access system in various ways, e.g. restrict access
according to nodes
according to taxonomy classification (taxonomy_access), or
according
to user groups (og).

I'm not sure if there's a node access module in contrib to
restrict
access according to node type, but if there isn't, it
shouldn't be too
hard to develop. This would probably be the best approach to
implementing more fine-grained access according to node
type.

Cheers,
Jaza.

On 12/29/06, Zohar Stolar <z.stolargmail.com> wrote:
>
> (might arrive twice... excuse me if it does)
>
>  I was looking through Drupal.org to find if there is
work towards
> granulating the permissions table a bit more, by adding
a way to limit
> administer/access to nodes by type.
>  The idea (which has certainly been raised before) is
to add, next to:
>
>  "create TYPE content", - adding new nodes of
that content type
>  "edit own TYPE content", - editing the
contents of own nodes of that
> content type
>  "edit TYPE content", - editing the contents
of all nodes of that content
> type (whether or not the user has right to create
nodes)
>
>  two more possibilities:
>
>  "view TYPE content" - roles that are allowed
to view the content type's
> nodes
>  "administer TYPE content" - roles that are
allowed to modify the publishing
> options on all nodes of that content type
>
>  I encounter more and more situations where I want to
delegate the
> publishing options permission to a specific role, but
only to one content
> type, otherwise I have to give the person control over
the whole site's
> content.
>
>  Such a change should be done through core, so actually
my questions are:
>  Is there any work on this direction / open issue?
>  Are there already any conclusions?
>  Should I start writing a patch  ?
>
>  Cheers,
>  Zohar
Even more flexibility in content management
user name
2006-12-29 01:11:45
A great idea. As a user active in our support forums, I would also love to see "view own TYPE content&quot;. For some of the other there are roundabout ways to achieve, using taxonomy access control, but for "view own" there is none. Requested use cases for private workspaces do exist, and the current ways are rather convoluted (1-user OG groups, 1-user user categories, unpublished nodes... and the like)


On 12/28/06, Zohar Stolar < z.stolargmail.com">z.stolargmail.com> wrote:

(might arrive twice... excuse me if it does)


I was looking through Drupal.org to find if there is work towards granulating the permissions table a bit more, by adding a way to limit administer/access to nodes by type.
The idea (which has certainly been raised before) is to add, next to:

&quot;create TYPE content&quot;,
- adding new nodes of that content type
"edit own TYPE content&quot;, - editing the contents of own nodes of that content type
"edit TYPE content&quot;, - editing the contents of all nodes of that content type (whether or not the user has right to create nodes)

two more possibilities:

&quot;view TYPE content&quot;
- roles that are allowed to view the content type's nodes
&quot;administer TYPE content&quot; - roles that are allowed to modify the publishing options on all nodes of that content type

I encounter more and more situations where I want to delegate the publishing options permission to a specific role, but only to one content type, otherwise I have to give the person control over the whole site's content.

Such a change should be done through core, so actually my questions are:
Is there any work on this direction / open issue?
Are there already any conclusions?
Should I start writing a patch ?

Cheers,
Zohar



--
Zohar Stolar  &nbsp;| &nbsp; זהר סטולר
לינווייט תשתיות תוכן קהילתיות

Even more flexibility in content management
user name
2006-12-29 01:16:03
A bit off-topic and not super critical, but this will also need to spur a discussion of a more manageable access control page if we have something like 5 perms for each content type. Is there an issue/any ideas on how to simplify the access control page? Or, is a super long matrix format still the best way to go?
Rob Roy Barreca
Founder and COO
Electronic Insight Corporation
http://www.electronicinsight.com
electronicinsight.com">robelectronicinsight.com


Zohar Stolar wrote:
gmail.com" type="cite">

(might arrive twice... excuse me if it does)


I was looking through Drupal.org to find if there is work towards granulating the permissions table a bit more, by adding a way to limit administer/access to nodes by type.
The idea (which has certainly been raised before) is to add, next to:

"create TYPE content",
- adding new nodes of that content type
"edit own TYPE content", - editing the contents of own nodes of that content type
"edit TYPE content", - editing the contents of all nodes of that content type (whether or not the user has right to create nodes)

two more possibilities:

"view TYPE content"
- roles that are allowed to view the content type's nodes
"administer TYPE content" - roles that are allowed to modify the publishing options on all nodes of that content type

I encounter more and more situations where I want to delegate the publishing options permission to a specific role, but only to one content type, otherwise I have to give the person control over the whole site's content.

Such a change should be done through core, so actually my questions are:
Is there any work on this direction / open issue?
Are there already any conclusions?
Should I start writing a patch ?

Cheers,
Zohar



--

Zohar Stolar   |   זהר סטולר
לינווייט תשתיות תוכן קהילתיות
Even more flexibility in content management
user name
2006-12-29 01:26:26
On 12/28/06, Rob Barreca <robelectronicinsight.com>
wrote:
>  A bit off-topic and not super critical, but this will
also need to spur a
> discussion of a more manageable access control page if
we have something
> like 5 perms for each content type. Is there an
issue/any ideas on how to
> simplify the access control page? Or, is a super long
matrix format still
> the best way to go?

Until someone comes up with a brilliant replacement UI, I
think that's it.

Are there any similar models from other systems that we
could copy?  I
don't know of any good ones off the top of my head.

Greg
Even more flexibility in content management
user name
2006-12-29 01:33:12
On 12/28/06, Greg Knaddison - GVS < Greggrowingventuresolutions.com">Greggrowingventuresolutions.com> wrote:
On 12/28/06, Rob Barreca < robelectronicinsight.com">robelectronicinsight.com> wrote:
>; &nbsp;A bit off-topic and not super critical, but this will also need to spur a
> discussion of a more manageable access control page if we have something
> like 5 perms for each content type. Is there an issue/any ideas on how to
> simplify the access control page? Or, is a super long matrix format still
> the best way to go?

Until someone comes up with a brilliant replacement UI, I think that's it.

Are there any similar models from other systems that we could copy? ; I
don't know of any good ones off the top of my head.

There is also the issue of when you have more than 5 or so roles, and the list
goes to the right beyond the screen.

Some alternatives were proposed some time back.

One of them (was it by Konstantin K?) was to use css to highlight the column titles
(role names) on the line that has the cursor on it.

Another was to have collapsible.

It is a tough usability one to tackle, specially scaling well for many roles and
many modules and many permissions per module.

Even more flexibility in content management
user name
2006-12-29 01:42:33
Agreed that collapsible fieldsets and css-hovering might be
helpful. If
I remember correctly there is an issue to add the role name
to the
checkbox title as well, and jQuery could be added in various
ways too.

It should also be noted that in 5.x one can go to
admin/user/roles and
edit permissions on a per-role basis. Although now that I
look at it the
"edit permissions" link isn't shown for anonymous
and authenticated
roles, which seems to be a bug.

Another implication is that it might be helpful to edit
permissions on a
per-module basis (i.e. across all roles). Maybe we could add
links to
this in the status message when enabling a module (or
modules).

.ck

Khalid B wrote:
> On 12/28/06, *Greg Knaddison - GVS* <Greggrowingventuresolutions.com
> <mailto:Greggrowingventuresolutions.com>> wrote:
> 
>     On 12/28/06, Rob Barreca <robelectronicinsight.com
>     <mailto:robelectronicinsight.com>> wrote:
>     >  A bit off-topic and not super critical, but
this will also need
>     to spur a
>     > discussion of a more manageable access control
page if we have
>     something
>     > like 5 perms for each content type. Is there
an issue/any ideas on
>     how to
>     > simplify the access control page? Or, is a
super long matrix
>     format still
>     > the best way to go?
> 
>     Until someone comes up with a brilliant replacement
UI, I think
>     that's it.
> 
>     Are there any similar models from other systems
that we could copy?  I
>     don't know of any good ones off the top of my head.
> 
> 
> There is also the issue of when you have more than 5 or
so roles, and
> the list
> goes to the right beyond the screen.
> 
> Some alternatives were proposed some time back.
> 
> One of them (was it by Konstantin K?) was to use css to
highlight the
> column titles
> (role names) on the line that has the cursor on it.
> 
> Another was to have collapsible.
> 
> It is a tough usability one to tackle, specially
scaling well for many
> roles and
> many modules and many permissions per module.
> 
Even more flexibility in content management
user name
2006-12-29 01:50:09
On Dec 28, 2006, at 5:33 PM, Khalid B wrote:

> There is also the issue of when you have more than 5 or
so roles,  
> and the list
> goes to the right beyond the screen.

it's a shame we lost the ability between 4.7.x and 5.x to
click on a  
role name and get a page with *just* the column for that
role. : 
(  that's a handy feature, and totally simplifies the
problem of not  
being sure which role you're assigning perms to when you
have a bunch  
of roles.  i think we're going to miss it in 5.x sites. 
seems like a  
small step backwards in usability, not sure when/why this
was  
removed... maybe it was seen as too much of a weird,
advanced UI  
trick, and people didn't even realize it was there or
something.

*shrug*

-derek


[1-10] [11-20] [21-25]

about | contact  Other archives ( Real Estate discussion Medical topics )