Modify

Opened 18 years ago

Last modified 8 years ago

#756 new enhancement

RFE: Forum Based Permission

Reported by: anonymous Owned by:
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 13 years ago.
basic implementation allowing forum- and topic-specific permissions

Download all attachments as: .zip

Change History (23)

comment:1 Changed 18 years ago by chtaylo3@…

Summary: Forum Based PermissionRFE: Forum Based Permission

Attaching e-mail address to this RFE.

comment:2 Changed 18 years ago by chtaylo3@…

Cc: chtaylo3@… added; anonymous removed

whoops, forgot to add to cc

comment:3 Changed 18 years ago by Noah Kantrowitz

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

comment:4 Changed 18 years ago by Radek Bartoň

Status: newassigned

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 18 years ago by Noah Kantrowitz

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

comment:6 Changed 17 years ago by A. Przygienda

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 11 years ago by Ryan J Ollos (previous) (diff)

comment:7 Changed 16 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 16 years ago by Radek Bartoň

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 13 years ago by Simon Stelling

Trac Release: 0.90.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 13 years ago by Simon Stelling

basic implementation allowing forum- and topic-specific permissions

comment:10 in reply to:  description Changed 11 years ago by Steffen Hoffmann

Owner: changed from Radek Bartoň to Steffen Hoffmann
Priority: normalhigh

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 ; Changed 11 years ago by Steffen Hoffmann

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 11 years ago by Steffen Hoffmann

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 11 years ago by Steffen Hoffmann

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 11 years ago by Steffen Hoffmann

In 13921:

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

comment:15 Changed 11 years ago by Steffen Hoffmann

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 10 years ago by Steffen Hoffmann

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 10 years ago by Steffen Hoffmann

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 10 years ago by Steffen Hoffmann

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 10 years ago by Steffen Hoffmann

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 10 years ago by Steffen Hoffmann

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.

comment:21 Changed 8 years ago by Ryan J Ollos

Status: assignednew

comment:22 Changed 8 years ago by Ryan J Ollos

Owner: Steffen Hoffmann deleted

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.

Add Comment


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

 
Note: See TracTickets for help on using tickets.