Edgewall Software
Modify

Opened 8 years ago

Last modified 6 years ago

#3302 new enhancement

Add Permission Change Hooks to Trac

Reported by: trac@… Owned by: osimons
Priority: normal Milestone: next-major-releases
Component: general Version: devel
Severity: normal Keywords: permission consider
Cc:
Release Notes:
API Changes:

Description

summary says most of it, attaching a patch.

basically, allow plugins to listen for permission changes (i've written an svn_authz generating plugin that would like to know when to rebuild the file)

Attachments (1)

permission_hooks.patch (1.7 KB) - added by trac@… 8 years ago.
patch to add an IPermissionChangeListener

Download all attachments as: .zip

Change History (9)

Changed 8 years ago by trac@…

patch to add an IPermissionChangeListener

comment:1 in reply to: ↑ description ; follow-up: Changed 8 years ago by eblot

Replying to trac@anarkystic.com:

basically, allow plugins to listen for permission changes (i've written an svn_authz generating plugin that would like to know when to rebuild the file)

I understand how this can work with the WebAdmin plugin as the plugin runs in the same Python VM than the listener, but how such a plugin would be notified about the permission changes that are made from trac-admin, for example?

comment:2 in reply to: ↑ 1 ; follow-up: Changed 8 years ago by athomas

Replying to eblot:

I understand how this can work with the WebAdmin plugin as the plugin runs in the same Python VM than the listener, but how such a plugin would be notified about the permission changes that are made from trac-admin, for example?

For reference: as mentioned by cboos, this is common to several locations in Trac.

comment:3 follow-up: Changed 8 years ago by eblot

I don't know mod_python, but would there be a way to receive the "reload" signal from Apache2 (apache2ctl graceful) and use this signal to invalidate all the caches and propagate this signal to some kind of "IRefreshListener"?

comment:4 in reply to: ↑ 2 Changed 8 years ago by cboos

Replying to athomas:

Right, and to expand a bit and this subject, I've written up a summary of a discussion on #trac with mabx: TracDev/JournalingProposal

comment:5 in reply to: ↑ 3 ; follow-up: Changed 8 years ago by cboos

Replying to eblot:

I don't know mod_python, but would there be a way to receive the "reload" signal from Apache2 (apache2ctl graceful) …

I thought that a apache2ctl graceful would restart the sub-processes in the prefork model, no? I mean, after a code upgrade, I always use graceful and this seems to be enough to make all the subsequent requests reach upgraded servers.

comment:6 in reply to: ↑ 5 Changed 8 years ago by eblot

I thought that a apache2ctl graceful would restart the sub-processes in the prefork model, no?

I guess you're right: I don't know well how mod_python and Apache articulate, but it seems that with the prefork model, any preforked child that does not serve a request at the time the graceful signal is received is killed and a new one is started.

Anyway, that does not solve the whole issue: it means that when a configuration change is made to Trac the web server needs to be restarted, which means that a Trac admin needs to have sufficient permissions to restart the whole Apache server.

comment:7 Changed 8 years ago by cboos

  • Keywords permission consider added
  • Milestone set to 1.0

Not entirely sold on the idea, but I think it s worth considering. This would be a situation where we'd need "change notification" on something else than Trac resources.

comment:8 Changed 6 years ago by osimons

  • Milestone changed from 1.0 to 0.12
  • Owner changed from jonas to osimons

I have written some very similar-sounding code to re-create the svn_authz file on every permission change from webadmin, and without hooks it really isn't pretty… For such save-events, 'regular' post- or pre-processing won't work as save of anything always trigger a req.redirect() if successful.

It does make sense to notify permission changes, and it makes little difference if it is Trac resources or not. 'User' is very much a Trac entity at least, and for 0.12 or later we'll hopefully also have a more capable user model and api.

As for this not being supported by trac-admin, that would not be the only mismatch between these two interfaces. For instance a trac-admin <env> wiki load <dir> does not call the wiki change listeners. Such mismatches are not ideal, but that perspective I think is more a discussion about refactoring the console script.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new The owner will remain osimons.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from osimons to anonymous. Next status will be 'assigned'.
Author


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

 
Note: See TracTickets for help on using tickets.