Ticket #10421 (closed enhancement: wontfix)

Opened 8 months ago

Last modified 4 weeks ago

Do we really need to implement permissions in this plugin?

Reported by: rjollos Assigned to: 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

Change History

10/03/12 18:21:41 changed 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?.

10/04/12 00:16:51 changed by rjollos

  • cc changed from jun66j5,rjollos to jun66j5.
  • description changed.

10/05/12 19:53:38 changed 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.

10/05/12 19:58:13 changed by rjollos

  • keywords set to permissions.

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.

10/11/12 22:19:55 changed 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?

10/19/12 10:15:15 changed by rjollos

  • owner changed from saigon to rjollos.
  • priority changed from normal to high.

10/19/12 10:17:02 changed by rjollos

  • status changed from new to assigned.

04/22/13 19:02:56 changed by rjollos

  • status changed from assigned to closed.
  • resolution set to wontfix.

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

Add/Change #10421 (Do we really need to implement permissions in this plugin?)




Change Properties
Action