Add Permission Change Hooks to Trac

[trac@…]

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)

[trac@…]

patch to add an IPermissionChangeListener

[Emmanuel Blot]

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?

[Alec Thomas]

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.

[Emmanuel Blot]

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"?

[Christian Boos]

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

[Christian Boos]

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.

[Emmanuel Blot]

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.

[Christian Boos]

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.

[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.