RFE: Forum Based Permission

[anonymous]

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!

[chtaylo3@…]

Attaching e-mail address to this RFE.

[chtaylo3@…]

whoops, forgot to add to cc

[Noah Kantrowitz]

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

[Radek Bartoň]

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.

[Noah Kantrowitz]

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

[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

@@ -3 +3 @@
 from datetime import *
 
 from trac.core import *
-from trac.resource import Resource
 from trac.mimeview import Context
 from trac.perm import PermissionError
 from trac.web.chrome import add_stylesheet, add_script, add_ctxtnav
@@ -969 +968 @@
             row['topics'] = row['topics'] or 0
             row['replies'] = row['replies'] and int(row['replies']) or 0
             row['time'] = format_datetime(row['time'])
-
-            if context.req.perm.has_permission('DISCUSSION_VIEW',Resource('forum',id=row['id'])):
-                forums.append(row)
+            forums.append(row)
 
         # Compute count of new replies and topics.
         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.

[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 !

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

[Simon Stelling]

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

[Simon Stelling]

basic implementation allowing forum- and topic-specific permissions

[Steffen Hoffmann]

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.

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

[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

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

[Steffen Hoffmann]

In 13921:

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

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

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

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

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

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

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