Opened 6 years ago

Closed 5 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 Ryan J Ollos)

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 6 years ago by Ryan J Ollos

Summary: Do we really to implement permissions for this plugin?Do we really need to implement permissions in this plugin?

comment:2 Changed 6 years ago by Ryan J Ollos

Description: modified (diff)

comment:3 Changed 6 years ago by yosiyuki

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.

comment:4 Changed 6 years ago by Ryan J Ollos

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 6 years ago by Ryan J Ollos

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 6 years ago by Ryan J Ollos

Owner: changed from yosiyuki to Ryan J Ollos
Priority: normalhigh

comment:7 Changed 6 years ago by Ryan J Ollos

Status: newassigned

comment:8 Changed 5 years ago by Ryan J Ollos

Resolution: wontfix
Status: assignedclosed

I'm going to leave it as-is for now.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted.

Add Comment

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

Note: See TracTickets for help on using tickets.