New user missing in 'session' table.

[Thomas Moschny]

I created a new user via the Web GUI, giving him an account name, long name, email, and password - everything looked fine. That user did not log in so far.

Now, he was set as the owner of a ticket, but the notificiations for that ticket are not sent to his email address.

Seems the reason is this: while the session_attribute table had been populated, the session table lacks an entry for the user (and as he did not log in yet, this wasn't fixed automatically), causing env.get_known_users() to not list that user and his email address.

Versions:

• Trac 0.11.8dev-r10236
• TracAccountManager 0.3.2

Configuration: Passwords are stored in a htpasswd file:

[account-manager]
account_changes_notify_addresses = ...
force_passwd_change = False
generated_password_length = 8
htpasswd_hash_type = crypt
notify_actions = new,change,delete
password_file = /path/to/htpasswd
password_store = HtPasswdStore
persistent_sessions = False
refresh_passwd = False
user_lock_max_time = 0
verify_email = False

[components]
acct_mgr.* = enabled
acct_mgr.db.sessionstore = disabled
acct_mgr.htfile.htdigeststore = disabled
acct_mgr.http.httpauthstore = disabled
acct_mgr.pwhash.htdigesthashmethod = enabled
acct_mgr.svnserve.svnservepasswordstore = disabled
acct_mgr.web_ui.emailverificationmodule = disabled
acct_mgr.web_ui.registrationmodule = disabled

[Steffen Hoffmann]

Thanks for taking your time to report your experience with the current stable version.

I wish you had looked into existing tickets for this plugin and considered commenting related ones, i.e. #6318, #9090 and #9252.

Replying to thomas.moschny@gmx.de:

I created a new user via the Web GUI, giving him an account name, long name, email, and password - everything looked fine. That user did not log in so far.
Now, he was set as the owner of a ticket, but the notificiations for that ticket are not sent to his email address.

Well, while your following assertions on the technical reason behind are mostly true, I like to speak-up against any policy, that allows assigning tickets to a user before his/her first login. I don't see why this must, or even should work. Always give permission first, obligation later on, right?

I'm in risk of being called-out for a questionable, philosophical attitude here, I know. But my utter feeling is that Trac actually does a good job in this situation. I'm rather not convinced by now, that AccountManagerPlugin should work around this feature and fake a suitable user session for you.

At the very least it's far more important to fix preservation of user attributes in the new user procedure across first login as hinted in the tickets mentioned above.

[Ryan J Ollos]

Also sounds like the underlying cause of the issue I reported in #9755, which we closed as a duplicate of #9252.

[anonymous]

Replying to hasienda:

Thanks for taking your time to report your experience with the current stable version.

I hope that wasn't meant as ironic as it sounds ;)

I wish you had looked into existing tickets for this plugin and considered commenting related ones, i.e. #6318, #9090 and #9252.

Indeed I had a brief look.

#6318 and #9090 are not related, they're about verification and confirmation mails.

#9252 is related, but different: there, entries in the session table are being created, but with a authenticated==0, and additional entries being created lateron (instead of updating the existing one).

This bug here was about no entry in session being created at all. As far as I understand the Trac database schema, it doesn't make sense to have entries in session_attribute with some sid, if there's no accompanying row for the very same sid in session.

But, I just realized, that from the perspective of env.get_known_users(), this doesn't make a difference; so in the end, we might close this bug also as a duplicate of #9252.

Let me first respond on this, though:

Well, while your following assertions on the technical reason behind are mostly true, I like to speak-up against any policy, that allows assigning tickets to a user before his/her first login. I don't see why this must, or even should work. Always give permission first, obligation later on, right?

Well, user has permission to log-in already. So, I can't see why this would violate the "permission first, obligation later on" policy.

I'm in risk of being called-out for a questionable, philosophical attitude here, I know. But my utter feeling is that Trac actually does a good job in this situation. I'm rather not convinced by now, that AccountManagerPlugin should work around this feature and fake a suitable user session for you.

While I am not sure this will convince you, here's our use case: We occasionally create a "support" account when we deploy a Trac instance for a customer, with an email address of the form "support@…", and bugs for certain components will get automatically assigned to this account. Of course for that to work, ticket notifications must be sent to the associated email address, even if nobody actually logs into that account.

Finally (and I am going to add that same comment to #9252), it is totally unclear to me, why you are calling a user entry that was made by an administrator a "fake" entry. We are not talking about self-registration here, but about totally clear processes as done in some company. If an administrator creates an account, the natural thing is to assume he knows what he or she does, and all the information entered is valid. (Of course errors happen, but this is not the normal case.)

[Steffen Hoffmann]

(In [11826]) AccountManagerPlugin: Hotfix for pending user-registration issue, refs #9079, #9252, #9843 and #9090.

Now the reversion of [10520] done by [10585] is completed, although there are many related changes and improvements in-between, so this is not quite the same code as before.

Taking the chance to update now obsolete configuration examples in README too.

This has already open for much too long, so let's ditch the rather esoteric considerations of authenticated user entries in Trac db table session for now and move on.

Big sorry, that this took that much time, and thanks to Peter Stuge for finally pushing me to it tonight.

[Steffen Hoffmann]

Replying to anonymous:

Replying to hasienda:

Thanks for taking your time to report your experience with the current stable version.

I hope that wasn't meant as ironic as it sounds ;)

I wish you had looked into existing tickets for this plugin and considered commenting related ones, i.e. #6318, #9090 and #9252.

Indeed I had a brief look.

#6318 and #9090 are not related, they're about verification and confirmation mails.

You'll see that I've been still right with that. You've still got your point for calling upon me about the "fake" entry thing. Well that has almost proven to be my biggest errors with this plugin, sorry again.

[Ryan J Ollos]

I can confirm that r11826 fixes the issue on my Trac installation.

[Steffen Hoffmann]

Replying to rjollos:

I can confirm that r11826 fixes the issue on my Trac installation.

The feedback is much appreciated, thanks. Glad to know, that this major issue is gone after a rather long struggle.

[Steffen Hoffmann]

(In [12398]) AccountManagerPlugin: Releasing version 0.4, pushing development to acct_mgr-0.5dev.

Availability of that code as stable release closes #874, #3459, #4677, #5295, #5691, #6616, #7577, #8076, #8685, #8770, #8791, #8990, #9052, #9079, #9090, #9139, #9246, #9252, #9547, #9618, #9676, #9843, #9852, #9940, #10023, #10028, #10123, #10142, #10204, #10276, #10397, #10412, #10594, #10625 and #10644.

Some more issues have been worked-on, yet without confirmed resolution, refs #5464 (for JiraToTracIntegration), #8927 and #10134.

And finally there are some issues and enhancement requests showing progress, but known to require more work to resolve them satisfactorily, refs #843, #1600, #5964, #8217, #8933.

Thanks to all contributors and followers, that enabled and encouraged a good portion of this development work.