Opened 12 years ago
Closed 12 years ago
#10421 closed enhancement (wontfix)
Do we really need to implement permissions in this plugin?
Reported by: | Ryan J Ollos | Owned by: | Ryan J Ollos |
---|---|---|---|
Priority: | high | Component: | BookmarkPlugin |
Severity: | normal | Keywords: | permissions |
Cc: | Jun Omae | Trac Release: | 0.12 |
Description (last modified by )
I've been thinking lately about whether the permissions for this plugin offer any value. The plugin should be disabled for anonymous
users, but for other users, what is the value of being able to grant the feature to some users, and not other users?
What use cases do people have for making use of the permissions? Would it be a problem to just drop the permissions from the plugin? The bookmarks feature seems to be pretty benign; I can't see the harm in providing it to everyone. Can anyone think of security holes that would be opened by dropping the permission? Dropping the permission would certainly simplify installation.
The BOOKMARK_MODIFY
is not currently used, and I can't see how it could be useful even as features are added. Is there a use case for allowing users to view bookmarks, but not add them? The only use-case I think of is to provide users with a set of read-only bookmarks, but can anyone actually envision using a feature like that in practice?
An alternative to permissions would be to have a user preference, so that users not wanting the feature could disable it.
What brought this to mind again, and caused me to raise a ticket, was the thought of suggesting to include the feature in the Bloodhound project, and simplifying the installation in order to make that a more realistic possibility.
Attachments (0)
Change History (8)
comment:1 Changed 12 years ago by
Summary: | Do we really to implement permissions for this plugin? → Do we really need to implement permissions in this plugin? |
---|
comment:2 Changed 12 years ago by
Description: | modified (diff) |
---|
comment:3 Changed 12 years ago by
comment:4 Changed 12 years ago by
Keywords: | permissions added |
---|
Thanks a lot for your comments. It is invaluable to get a response from the original author on an issue like this. I'm going to ask on the question on the mailing list, as to whether anyone would miss the permissions, and I'll follow-up here before making any changes.
comment:5 Changed 12 years ago by
jun66j5: If I make any change, I want to make sure you are okay with it as well. Do you have a preference to leave or remove the permission?
comment:6 Changed 12 years ago by
Owner: | changed from yosiyuki to Ryan J Ollos |
---|---|
Priority: | normal → high |
comment:7 Changed 12 years ago by
Status: | new → assigned |
---|
comment:8 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
I'm going to leave it as-is for now.
Honestly, I had no deep thought when I implement permissions in this plugin. What I wanted was new feature should be fully controlled by administrator and Trac's permission system is easy enough to implement , so that I implement it.
The only situation I can imagine when we need permissions in this plugin is as following. In the team who has very strict "white list like" policy, which is, "if there is good reason to give the permission, the user can get the permission otherwise admin won't give it", administrators have to control bookmark feature user by user. Though it should be rare.
Anyway, I don't have any good reason to keep permissions in this plugin.