Opened 19 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 )
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.
Notes
- if
repository_dir
is not set intrac.ini
, versioncontrol actions are automatically disabled, and the administrator cannot remove the following permissions:BROWSER_VIEW
,CHANGESET_VIEW
,FILE_VIEW
,LOG_VIEW
- I think #2307 is the expression of this general issue, specialized for TracReports.
Attachments (0)
Change History (5)
comment:1 by , 19 years ago
Description: | modified (diff) |
---|
comment:2 by , 18 years ago
Milestone: | → 0.11 |
---|
comment:3 by , 18 years ago
Keywords: | permission added |
---|
comment:4 by , 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 , 17 years ago
Milestone: | 0.11.1 |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
#4171 was marked as duplicate.