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)
Change History (23)
comment:1 Changed 18 years ago by
Summary: | Forum Based Permission → RFE: Forum Based Permission |
---|
comment:2 Changed 18 years ago by
Cc: | chtaylo3@… added; anonymous removed |
---|
whoops, forgot to add to cc
comment:3 Changed 18 years ago by
This should probably wait until Alec's new permission model ends up in Trac.
comment:4 Changed 18 years ago by
Status: | new → 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 18 years ago by
The permission model includes subject-based checks, which is exactly what is needed for this.
comment:6 follow-up: 11 Changed 17 years ago by
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 3 3 from datetime import * 4 4 5 5 from trac.core import * 6 from trac.resource import Resource7 6 from trac.mimeview import Context 8 7 from trac.perm import PermissionError 9 8 from trac.web.chrome import add_stylesheet, add_script, add_ctxtnav … … 969 968 row['topics'] = row['topics'] or 0 970 969 row['replies'] = row['replies'] and int(row['replies']) or 0 971 970 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) 975 972 976 973 # Compute count of new replies and topics. 977 974 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.
comment:7 Changed 16 years ago by
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
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
Trac Release: | 0.9 → 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 13 years ago by
Attachment: | finegrained_permissions.patch added |
---|
basic implementation allowing forum- and topic-specific permissions
comment:10 Changed 11 years ago by
Owner: | changed from Radek Bartoň to Steffen Hoffmann |
---|---|
Priority: | normal → 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 follow-up: 18 Changed 11 years ago by
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:18 Changed 10 years ago by
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:21 Changed 8 years ago by
Status: | assigned → new |
---|
comment:22 Changed 8 years ago by
Owner: | Steffen Hoffmann deleted |
---|
Attaching e-mail address to this RFE.