#1671 closed task (fixed)
[trac] Port notify.py local modification to newer version
Reported by: | strk | Owned by: | strk |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | SysAdmin/Trac | Keywords: | trac |
Cc: | frankw, neteler |
Description
Reading https://wiki.osgeo.org/wiki/Trac_Instances#Local_Customizations I found out there were local modifications to the "notification.py" module of Trac to lookup emails of OSGeo users. I dubt this local modification was ported when trac was updated.
Frank: what was the local modification useful for ? How to test if it works ?
Change History (26)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
This might be related:
Trac, all OSGeo instances, suddenly stopped delivering email notifications to my inbox. I have noticed, that Full Name and E-mail fields in all https://trac.osgeo.org/<PROJET>/prefs I use are empty.
Once I fill those in, Trac e-mail notifications work again.
comment:3 by , 9 years ago
Do you remember approximately when did things stop working ? So to relate it on either trac version upgrade or something different.
comment:4 by , 9 years ago
I have not received notification about new GEOS ticket 7 days ago (https://trac.osgeo.org/geos/ticket/778) - I used to receive all new tickets emailed. But, surely, I did not receive notification with comments to ticket I reported today and that made me check what is going on.
comment:5 by , 9 years ago
FWIW, trac/GRASS delivers emails.
Perhaps a potential issue in GEOS or related to mloskot's email could be spotted in the mail.log file on trac? (also /etc/aliases comes to mind which might interfere).
follow-up: 16 comment:6 by , 9 years ago
Markus: do you have your name and address in https://trac.osgeo.org/grass/prefs ? (General tab)
comment:7 by , 9 years ago
Mateusz: according to the /prefs/ text, those settings are stored in a session and the session is referenced from a cookie. If I recall correctly those cookies expire with the session, could you check with a cookie inspector ?
I'm looking in the database and do see your preferences in the session_attribute table under the sid value of 'mloskot', but for example I don't see Markus ones in the grass database instance.
comment:8 by , 9 years ago
Sandro, AFAIK, the cookie is used only if a user is not signed in to the Trac with username/password.
I don't see those values stored in any of cookies associated with trac.osgeo.org.
comment:9 by , 9 years ago
Could be. In any case there are only 3 sessions in GEOS that have an 'email' attribute, 1 in GRASS and 7 in PostGIS.
Of this total of 11, yours and the one for "googlerocks" (a spammer) are the only ones named after an actual user.
The other 10 also look like having fake emails.
So I'm still curious to know how Markus receives his notifications, if at all
comment:10 by , 9 years ago
I no longer receive email notifications from Trac ticket changes and I see that https://trac.osgeo.org/gdal/prefs is now empty. Such issue (empty email) occured several months ago when Trac version was upgraded and I add to enter it back at that time. I suspect that all users are affected by the emptied email ?
comment:11 by , 9 years ago
I wonder if it's been myself wiping out the session attributes while fighting spammers. Cannot exclude that (but I guess I could look at the backups to verify). The other possibility is that session attributes are removed when they do not have a match in the session itself (which is more likely that I could have removed, thinking it would hold no important info). I'll try the latter.
In any case, it doesn't seem nice to require entering preferences in each and every instance. We're the same community here, using a single sign-on, so we should really aim at making this automatic. Besides, judging from the actual values in those attribute tables, chances are spammers are using notifications as a way to spam arbitrary email addresses, by writing them into the session preference.
For configuration, see https://trac.edgewall.org/wiki/TracNotification (but please dont' configure your instances independently, we want to use the global config as much as possible).
comment:12 by , 9 years ago
The PostGIS trac instance has been "forgetting" my name and email address for some time (years, I think). I enter it in, it sticks for some time (how long, I'm not sure), and eventually is wiped out. So it may not be related to a recent update.
comment:13 by , 9 years ago
Confirmed: wiping a session first makes the session attributes orphaned (so that /prefs/ results blanked out) and finally (on log-out) wipes the attributes. The oldest backup that I made myself was from 20160503 and did not have Mateusz' email in session_attribute, nor Even's (for GDAL instance).
Every clue points to this lack of port of a patch Frank Warmerdam applied to the notify.py script, to make it use the email registered with LDAP for figuring out users email.
So, it only takes someone to find that patch and port it (and ideally make it general and send upstream).
Daniel: I know you're always ready for new challenges ! :)
comment:14 by , 9 years ago
I've never had to enter anything in Preferences per each OSGeo Trac instance to get notifications working.
comment:16 by , 9 years ago
Replying to strk:
Markus: do you have your name and address in https://trac.osgeo.org/grass/prefs ? (General tab)
No, it is empty.
As a test, I just edited a ticket:
and the email notification reached the list (<<--- this is how we have set it up in grass-dev):
Looks all good here. Maybe this setting differs from other OSGeo projects but for us it is fine.
comment:17 by , 8 years ago
Reaching the list is not a problem. Reaching individual users is (like someone added in Cc, I guess)
comment:18 by , 8 years ago
Component: | Systems Admin → Trac |
---|---|
Owner: | changed from | to
comment:23 by , 8 years ago
Cc: | added |
---|
I've ported the changes, but cannot confirm they are working as expected
comment:24 by , 8 years ago
As trac supports considering unqualified names as addresses in a given domain, it could be less of an hack to setup dynamic aliases for OSGeo users
comment:26 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Thanks, everything works now :)
The wiki page references #39 for background