Modify

Opened 8 years ago

Last modified 4 months ago

#756 assigned enhancement

RFE: Forum Based Permission

Reported by: anonymous Owned by: hasienda
Priority: high Component: DiscussionPlugin
Severity: trivial Keywords:
Cc: chtaylo3@… Trac Release: 0.12

Description

It would be great if you could expand the permission system so that we can set permissions based on the Forum. For example, I may want to have a developers forum that is seperate from the users ... we may not want users reading the developers forum.

One possible way of doing this is to append the forum permission with a number that corresponds to the forum number. Forum# 0 could be a blanket "all forums". All Forum specific permissions would overwrite Forum# 0 permissions.

Just a thought, other than that .. GREAT PLUGIN!

Attachments (1)

finegrained_permissions.patch (18.1 KB) - added by simon.stelling@… 3 years ago.
basic implementation allowing forum- and topic-specific permissions

Download all attachments as: .zip

Change History (21)

comment:1 Changed 8 years ago by chtaylo3@…

  • Summary changed from Forum Based Permission to RFE: Forum Based Permission

Attaching e-mail address to this RFE.

comment:2 Changed 8 years ago by chtaylo3@…

  • Cc chtaylo3@… added

whoops, forgot to add to cc

comment:3 Changed 8 years ago by coderanger

This should probably wait until Alec's new permission model ends up in Trac.

comment:4 Changed 8 years ago by Blackhex

  • Status changed from new to assigned

To achieve dynamicly defined premissions in current Trac it would be necessary to append table with pairs (permission, forum) a make it configurable via WebAdmin or read pairs from config file. (pair could be single value as you suggested, but it still have to be stored somewhere). I don'ŧ know how would new permission system look like but I can wait for it, since I don't have much time to work on trac's plugins now.

comment:5 Changed 8 years ago by coderanger

The permission model includes subject-based checks, which is exactly what is needed for this.

comment:6 follow-up: Changed 7 years ago by prz

ok, here's a minimal 'hack' to get the forum permissions on authz_policy.c working, just added to api.py

  • api.py

    old new  
    33from datetime import * 
    44 
    55from trac.core import * 
    6 from trac.resource import Resource 
    76from trac.mimeview import Context 
    87from trac.perm import PermissionError 
    98from trac.web.chrome import add_stylesheet, add_script, add_ctxtnav 
     
    969968            row['topics'] = row['topics'] or 0 
    970969            row['replies'] = row['replies'] and int(row['replies']) or 0 
    971970            row['time'] = format_datetime(row['time']) 
    972  
    973             if context.req.perm.has_permission('DISCUSSION_VIEW',Resource('forum',id=row['id'])): 
    974                 forums.append(row) 
     971            forums.append(row) 
    975972 
    976973        # Compute count of new replies and topics. 
    977974        for forum in forums: 

That's 'nuff. For a better solution, the resource has to be maintained across the API properly and the permissions not
only asserted on operations but checked upfront with the
resource specified.

Last edited 4 months ago by rjollos (previous) (diff)

comment:7 Changed 6 years ago by fluzz

Sorry, I'm quite new to Trac and I don't understand how to use your proposed hack... With your modification, where and how do I define the per-forum permissions ?

Thanks for your great plugin !

comment:8 Changed 6 years ago by Blackhex

Uff, that's a really old ticket here :-). I should start doing something about it. I'm not sure how the patch will actually work now but it has someting to do with TracFineGrainedPermissions. BTW: I noticed that pach has inverted + and - signs.

comment:9 Changed 3 years ago by simon.stelling@…

  • Trac Release changed from 0.9 to 0.12

I needed the ability to have finegrained control. I extended the DiscussionPlugin to use the following resource identifiers:

  • Forums: discussion:forum/<FORUM_ID>
  • Topics: discussion:forum/<FORUM_ID>/topic/<TOPIC_ID>
  • Messages: discussion:forum/<FORUM_ID>/topic/<TOPIC_ID>/message/<MSG_ID>

With these, it is possible to configure read-write access down to topic-level (although I only use and tested forum-level permissions), e.g. with AuthzConfig:

    # protect forum 2 and all topics/messages contained in it. Attachments are not protected.
    [discussion:forum/2*]
    @stats = DISUCSSION_VIEW, DISCUSSION_APPEND, DISCUSSION_ATTACH
    * = !DISCUSSION_VIEW, !DISCUSSION_APPEND, !DISCUSSION_ATTACH
    
    # make all other forums available
    [discussion:forum/*]
    * = DISUCSSION_VIEW, DISCUSSION_APPEND, DISCUSSION_ATTACH

I will attach the patch in a second. Note the HACK regarding attachments, where I need to modify the resource ids. I am not sure how to solve this properly, but it works this way. If anybody has feedback regarding the patch, please do contact me at simon dot stelling at usz dot ch.!

Changed 3 years ago by simon.stelling@…

basic implementation allowing forum- and topic-specific permissions

comment:10 in reply to: ↑ description Changed 5 months ago by hasienda

  • Owner changed from Blackhex to hasienda
  • Priority changed from normal to high

Replying to anonymous:

It would be great if you could expand the permission system so that we can set permissions based on the Forum.

Agreed, I would even say 'mandatory' instead, especially because restricted/private topics and largely distributed moderation by numerous users are examples for typical use cases of fine-grained permissions in forums.

comment:11 in reply to: ↑ 6 ; follow-up: Changed 5 months ago by hasienda

Replying to prz:

ok, here's a minimal 'hack'
...
That's 'nuff. For a better solution, the resource has to be maintained across the API properly and the permissions not only asserted on operations but checked upfront with the resource specified.

While applying and reshaping the proposed patch I've thought the same. This is the way to go indeed.

comment:12 Changed 4 months ago by hasienda

In 13914:

DiscussionPlugin: Enable fine-grained resource permission checks, refs #756 and #11622.

Changes base on a patch proposal by Simon Stelling - thank you very much.

Notes on alterations:

  • constructing resources from realm resource for clarity and code reduction
  • resource ID parsing in different places justifies dedicated private method
  • 'DISCUSSION_ADMIN' inherits 'DISCUSSION_MODERATE' permission action, but permission checks need to check minimal requirement only
  • more PEP8 changes (excessive white-space inside brackets, line-wrap)
  • gradually adopt 'Yoda conditions' recently suggested as good coding style by lkraav

comment:13 Changed 4 months ago by hasienda

In 13916:

DiscussionPlugin: Correct issues with tag retrieval, refs #756 and #11706.

Resource construction must happen before its use in a tag provider method.
An additional private method enables code deduplication for forum data
retrieval.

comment:14 Changed 4 months ago by hasienda

In 13921:

DiscussionPlugin: Stop requests lacking view permission to whole realm, refs #756 and #11706.

comment:15 Changed 4 months ago by hasienda

In 13922:

DiscussionPlugin: Don't need to custom permission error, refs #756 and #11706.

This would be a reason to use the previous pattern. Thanks for the hint.

comment:16 Changed 4 months ago by hasienda

In 13936:

DiscussionPlugin: Reorganize search source code, refs #756 and #11706.

In fixing discussion resource links this is a follow-up to [13914].

The remains after moving db access code to model don't justify to keep
search as a separate module. Added search should help preventing further
regressions for this functionality.

comment:17 Changed 4 months ago by hasienda

In 13938:

DiscussionPlugin: Narrow user selection according to granted permissions, refs #756.

You should be able to choose only users with appropriate permissions as
moderators, and the same applies to subscriptions. This is still not 100%
correct, because ultately fine-grained permisions could affect this too.

comment:18 in reply to: ↑ 11 Changed 4 months ago by hasienda

Replying to hasienda:

Replying to prz:

For a better solution, the resource has to be maintained across the API properly and the permissions not only asserted on operations but checked upfront with the resource specified.

While applying and reshaping the proposed patch I've thought the same. This is the way to go indeed.

Looking at moderator and subscription assignments/selection you can see the truth clearly: Accurate users lists require permission checks for the discussion resource in question, not based on the 'discussion' realm level.

comment:19 Changed 4 months ago by hasienda

In 13942:

DiscussionPlugin: Hotfix for topic (attachment parent) Trac resource, refs #756 and #11800.

I've been expecting issues when moving on towards unified resources and
resource permissions. This is another hack before being able to associate
attachments with full resource path, not just topic, the current shortcut.

comment:20 Changed 4 months ago by hasienda

In 13944:

DiscussionPlugin: Review wiki macros and syntax provider code, refs #756 and #11706.

This includes a wide range of changes from adding another db access method to
api over moving SQL into model module to correcting resource ID as
required for fine-grained permission support.

Adding the missing import from trac.resource as follow-up to [9640] suggests
rare use of discussion WikiMacros so far.

Add Comment

Modify Ticket

Action
as assigned .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.