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

[eblot]

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

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.

[cboos]

#4171 was marked as duplicate.

[charles.butterfield@…]

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.

[cboos]

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