Edgewall Software

Opened 18 years ago

Closed 17 years ago

#2546 closed defect (duplicate)

Cannot remove default permissions when the module defining the action is disabled

Reported by: Emmanuel Blot Owned by: daniel
Priority: normal Milestone:
Component: admin/console Version: devel
Severity: minor Keywords: permission
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christopher Lenz)

When a new project ("environment") is created, a set of default permissions is automatically granted.

If the project administrator edits the project config file (trac.ini) to disable some module(s), following the documentation, the project ends up in a dead-lock situation:

trac-admin refuses to revoke existing permissions if the action is defined in the disabled component. This permission for this action has not been set by the administrator, but by the trac-admin script at project creation time.

This situation is quite confusing for the administrator: with the current implementation, he/she should first remove unwanted permissions for a module he/she does not want to use. If it fails to do so, he/she gets the infamous error message:

Command failed: <action> is not a valid action.


  1. if repository_dir is not set in trac.ini, versioncontrol actions are automatically disabled, and the administrator cannot remove the following permissions: BROWSER_VIEW, CHANGESET_VIEW, FILE_VIEW, LOG_VIEW
  2. I think #2307 is the expression of this general issue, specialized for TracReports.

Attachments (0)

Change History (5)

comment:1 by Christopher Lenz, 18 years ago

Description: modified (diff)

comment:2 by Christian Boos, 18 years ago

Milestone: 0.11

#4171 was marked as duplicate.

comment:3 by Christian Boos, 18 years ago

Keywords: permission added

comment:4 by charles.butterfield@…, 17 years ago

This sure seems like a bug. If something changes, such as the SVN repo being added, suddenly a bunch of permissions will reappear. Why not convert the error to a warning and remove the indicated entry from the database? Doesn't sound too hard, nor too dangerous, unless there is something really subtle going on.

When creating new trac projects, we run scripts that attempt to set strict permissions. Many projects have no associated SVN repo. The error messages and the bizarre confusion for the unwary admins who dig in and see that anonymous APPARENTLY has permissions that cannot be removed wastes a whole bunch of time on an ongoing (albeit sporadic) basis. We could just send all output into the bit bucket, but then we wouldn't know when something really did go wrong.

Disabling the check seems so trivial that I can't understand why it hasn't been done. The is no commentary to date that indicates what subtle concerns may exist.

comment:5 by Christian Boos, 17 years ago

Milestone: 0.11.1
Resolution: duplicate
Status: newclosed

This was actually fixed for 0.11, see r4359 and #2146.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain daniel.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from daniel to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.