Opened 4 years ago

Closed 3 years ago

#10421 closed enhancement (wontfix)

Do we really need to implement permissions in this plugin?

Reported by: rjollos Owned by: rjollos
Priority: high Component: BookmarkPlugin
Severity: normal Keywords: permissions
Cc: jun66j5 Trac Release: 0.12

Description (last modified by rjollos)

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 4 years ago by rjollos

  • Summary changed from Do we really to implement permissions for this plugin? to Do we really need to implement permissions in this plugin?

comment:2 Changed 4 years ago by rjollos

  • Description modified (diff)

comment:3 Changed 4 years ago by saigon

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 4 years ago by rjollos

  • 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 4 years ago by rjollos

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 4 years ago by rjollos

  • Owner changed from saigon to rjollos
  • Priority changed from normal to high

comment:7 Changed 4 years ago by rjollos

  • Status changed from new to assigned

comment:8 Changed 3 years ago by rjollos

  • Resolution set to wontfix
  • Status changed from assigned to closed

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

Add Comment

Modify Ticket

as closed The owner will remain rjollos.
The resolution will be deleted. Next status will be 'reopened'.

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

Note: See TracTickets for help on using tickets.