[Patch] Display full user names instead of user login

[michael.grundberg@…]

In some environments the user login names are cryptic since they are set by a central IT department using some number system or what else. It would be preferable to have trac display the full user names wherever possible so there is a fair chance to know who changed what.

Attached is a patch against the released version of 0.11rc2 which will display the full user names in all places which uses the Chrome.format_author function, if the user has set it in the preferences and the administrator has turned it on in the configuration. I also added the use of format_author in the assign to field of tickets, if it is configured to display a drop down list.

All existing tests run, but I did not create any new tests for this enhancement.

This patch might collide with ticket 2178.

[ebray <hyugaricdeau@…>]

I'm definitely +1 for this.

[anonymous]

I would definitely like see this rolled into the main trunk!

[cboos]

This looks interesting, but calling env.get_known_users is costly. So for one this should only be done if the show_full_names option is selected. Then, caching that information in the Chrome instance is not a good idea since there's currently no way to get notified when this information changes. Recomputing the cache in each format_author makes the cache useless and is of course too costly. One interim solution might be to cache it in the req.

A better solution should be found as part of the user API changes, planned for 0.13. I'm rescheduling this for 0.13, but feel free to propose an interim patch taking the ideas above (or better ones) into account.

[ebray <hyugaricdeau@…>]

cboos: Are any of your ideas for the user/group API documented, or is it just in your head for now? I'd be interested in talking about that at some point as I've done a bit of work related to that. I have a plugin that provides users and user meta data from an external DB, and monkey patches env.get_known_users among other things. But its current incarnation is kind of ugly, so I'd be interested in what your thoughts are on the subject.

[cboos]

Sorry, not even in my head, I was referring to various ideas floating around (see #2456) and the fact that there's a general agreement that some improvement is needed in this area and that it should happen hopefully not later than 0.13…

[cboos]

#2178 asked for the full name in one specific location, so I closed it as duplicate.

See also #3737, which discusses a complementary idea (showing nicknames).

[dserodio@…]

Couldn't the "create user" WebAdmin function invalidate the cache?

PS.: Why doesn't the spam filter let me post?

[Matthew Caron <Matt.Caron@…>]

I have attached an updated patch against trac 0.11.5. It expands on Michael's patch, munges it in to 0.11.5 so it (should) apply cleanly, and adds lookups in a couple of spots (ticket queries, etc.) which were missed.

[Matthew Caron <Matt.Caron@…>]

Show full names rev 2. (against trac 0.11.5)

[mian.hasan.khalil@…]

Another vote for seeing something like this integrated to the trunk.

[Hasan Khalil <mian.hasan.khalil@…>]

Show full names revision 3.

[Hasan Khalil <mian.hasan.khalil@…>]

I've added a patch for another couple of cases that were missed. There are definitely more in notification.py but I wasn't able to get it to play nice. I haven't really ever used python before, so do audit that code before you run it locally! I'd love to see someone else pick up where I left off with notification.py and finish the job. That seems to be really the only other place that e-mail obfuscation occurs instead of substituting with full names.

[Hasan Khalil <mian.hasan.khalil@…>]

Replying to cboos:

This looks interesting, but calling env.get_known_users is costly. So for one this should only be done if the show_full_names option is selected.

Fixed in attachment:trac-show_full_names-r3-0.11.5.diff​.

[cboos]

Replying to Hasan Khalil <mian.hasan.khalil@…>:

Replying to cboos:

This looks interesting, but calling env.get_known_users is costly. So for one this should only be done if the show_full_names option is selected.

Fixed in attachment:trac-show_full_names-r3-0.11.5.diff​.

Thanks! Patch looks good, you're on the right track ;-) Still:

• trac/ticket/web_ui.py, in old = chrome. chrome is not defined here. A bit of refactoring is needed here so that there's only one chrome = Chrome(self.env) in this method;
• The docstring for show_full_names should add a caveat saying: "This option is potentially resource intensive for sites with lots of users." (or anything better phrased);
• Finally, Chrome.user_map is caching some data coming from the database, and as such its content should be adequately updated when needed. This can be achieved using the cached attributes we introduced in 0.12. Some work should be done in order to find the proper places where the cache has to be invalidated.

[dekimsey@…]

Replying to cboos:

• Finally, Chrome.user_map is caching some data coming from the database, and as such its content should be adequately updated when needed. This can be achieved using the cached attributes we introduced in 0.12. Some work should be done in order to find the proper places where the cache has to be invalidated.

If a user's information is updated, persistent-processes will not pickup on the new information until they are reloaded. This is because the user_map is generated in env as cboos has noted. The hacky solution is to simply touch the trac.ini file to force it to reload.

[Vaclav Slavik <vslavik@…>]

I'm attaching modified version of the patch. Changes:

1. Fixed trac/ticket/web_ui.py problem. Chrome(self.env) is relatively cheap, so I just added it at the beginning of the function.
2. Docstring fixed.
3. Changed to show full name even to anonymous requests. Previously, show_full_names meant "show full names to users that would otherwise be shown unmangled email address", I think it makes more sense like this.
4. If showing email address is permitted, display Full Name <email@address.com> instead of Full Name. This is consistent with the way email addresses of unauthenticated users are shown by Trac. More importantly, it wouldn't be possible to contact registered submitters without this change.

I'm not sure if 4. is the right thing to do. Ideally, user names would be clickable links (either mailto: or using e.g. reCAPTCHA Mailhide), but that would be a huge change out of this patch's scope.

I didn't port the patch to 0.12 and its caching framework yet.

[cboos]

See also #9115 (focusing on the CC: field, closed as duplicate of the present ticket) and #3737 (alternative display of a 'nickname').

[KlauX]

Patch for Trac 0.12b1

[KlauX <klaux1@…>]

Replying to Vaclav Slavik <vslavik@…>:

I'm attaching modified version of the patch. Changes:

1. Fixed trac/ticket/web_ui.py problem. Chrome(self.env) is relatively cheap, so I just added it at the beginning of the function.
2. Docstring fixed.
3. Changed to show full name even to anonymous requests. Previously, show_full_names meant "show full names to users that would otherwise be shown unmangled email address", I think it makes more sense like this.
4. If showing email address is permitted, display Full Name <email@address.com> instead of Full Name. This is consistent with the way email addresses of unauthenticated users are shown by Trac. More importantly, it wouldn't be possible to contact registered submitters without this change.

I'm not sure if 4. is the right thing to do. Ideally, user names would be clickable links (either mailto: or using e.g. reCAPTCHA Mailhide), but that would be a huge change out of this patch's scope.

I didn't port the patch to 0.12 and its caching framework yet.

This patch is upside down?

[KlauX <klaux1@…>]

Revision 1 plus alterations…

[KlauX <klaux1@…>]

Revision 1 plus alterations…

[thijstriemstra]

Patch needs a review.

[thijstriemstra]

Increasing the priority of this enhancement, judging by the cc's.

[ajax]

This patch doesnt work with TRAC 0.12.2rc1

[anonymous]

I could not patch version 0.12.2. The diff failed in three places. I rolled back to 0.12 and ran the diff and everything patched fine. I added the show_full_names under the [trac] directive in the trac.ini and made sure that my full name was filled in under preferences but I cannot get this to work. Is there any other changes I need to make to implement this? Also I am running this under ubuntu so am I supposed to patch the /usr/local/lib/python2.6/dist-packages/ version or the /usr/lib/python2.6/dist-packages. Sorry, I am kind of a noob when it comes to this. Thanks a lot.

[Poly <polyflor@…>]

I am working on a working patch for 0.12.2. It should be postable by the end of this month.

[Poly <polyflor@…>]

Repaired, tested and enhanced patch for 0.12.2

[Poly <polyflor@…>]

Find enclosed the patch for 0.12.2 (r2).

• Fixed: works with 0.12.2
• Added: Using a cached attribute for 'known_users' (as discussed above)
• Added: Test cases for the global flags (show_email_addresses and show_full_names)
• Added: Ticket Owner and Reporter are clickable when shown in full and point to the reporting page (same as in unpatched versions)
• Open: Notification.py see comments above and also #7862

There is also an oddity I stumbled upon: If show_email_addresses is true and show_full_names is false the Reporter and Owner fields are shown as logins (as long as your logins do not contain an at-sign). This behaviour has been present ever since the show_email_addresses has been implemented. I did not touch this dial, because I do not know the intenion of the flag for the Reporter and Owner field in this case. If you like other behaviour you should be able to adapt the format_author() method. Last but not least that is why I provided some test cases.

Hope this helps.

[cboos]

Thanks for the patch, looks like a good start. From a cursory look:

• a few whitespace glitches in trac/web/chrome.py
• about know_users cached property:
  • you don't need to give an explicit id when caching a property in a Component class (see ​apidoc:api/trac_cache#trac.cache.cached)
  • s/tupel/tuple/, no need to describe the usage, it's a cached property
• just use self.known_users no need for self._user_map (it's even wrong to do so, at the latter will never get invalidated, once set)
• speaking of invalidation, this known_users property never gets invalidated, and this should at least be done in some session management operations (that's actually the difficult part and why further changes are needed until we can commit something like this)

[Poly <polyflor@…>]

interim patch (rev3) for 0.12.2

[Poly <polyflor@…>]

Replying to cboos:

From a cursory look:

• a few whitespace glitches in trac/web/chrome.py
• about know_users cached property:

[…] Thanks for setting the right stage for the cached attribute. I addressed your tips in the r3-0.12.2 patch.

• speaking of invalidation, this known_users property never gets invalidated, and this should at least be done in some session management operations (that's actually the difficult part and why further changes are needed until we can commit something like this)

I'd like to fix that too. I had a glance look in trac/web/session.py. I am not sure if this is the right (and the only) place to hook in the invalidation. This topic really needs more attention and time than I currently can provide. Some hints (if I am on the right track) could accelerate a solution for this. Thank you!

[framay <franz.mayer@…>]

Replying to cboos:

This looks interesting, but calling env.get_known_users is costly.

I am wondering, why Trac does not have any user table. A select * from user for example wouldn't probably that costly like env.get_known_users. Is there any ticket / request for a separate user table?

Furthermore all master data of users could be stored in that table, such as:

• name and forename (like already stored in session_attribute)
• email address (like already stored in session_attribute)
• phone number(s)
• room number
• location (address)
• department
• some more personell information about that person (knowledge, photo, etc.)
• etc.

Preference data could be stored as now in session_attribute.

[lkraav <leho@…>]

Replying to framay <franz.mayer@…>:

Replying to cboos:

This looks interesting, but calling env.get_known_users is costly.

I am wondering, why Trac does not have any user table. A select * from user for example wouldn't probably that costly like env.get_known_users. Is there any ticket / request for a separate user table?

#2456 is an all-time classic :>

[Hans-Peter Locher <locher.hanspeter@…>]

improved (rev3 + invalidation of cached known_users) patch for 0.12.2

[Hans-Peter Locher <locher.hanspeter@…>]

I've attached a new patch for Trac 12.2 with invalidation of the trac.web.chrome.Chrome.known_users

The invalidation works when changing the user attributes via trac-admin and when a user saves his prefs

[Hans-Peter Locher <locher.hanspeter@…>]

attachment:Trac-show_full_names-r4-0.12.2.patch​

[mhait@…]

I`ve downloaded ​http://download.edgewall.org/trac/Trac-0.12.2.zip and failed to apply patch onto it (source code from Trac-0.12.2.zip really differs from patch version). What am I doing wrong?

[jan.zilka@…]

I upgraded Trac 0.12 patched by r3 to 0.13dev and show_full_names does not work.

All seems ok, lines from patch are in the 0.13 code. Any idea?

[anonymous]

Patch works for 0.12.3, too :).

[anonymous]

Replying to Hans-Peter Locher <locher.hanspeter@…>:

I've attached a new patch for Trac 12.2 with invalidation of the trac.web.chrome.Chrome.known_users

The invalidation works when changing the user attributes via trac-admin and when a user saves his prefs

i'm using this patch but having an issue with email addresses

trac.ini is set to

show_email_addresses = false show_full_names = true

but full_names and email_addresses are both shown

show_email_addresses

appears to have no effect on my install (Trac 12.2.2, r4 patch)

am i missing a configuration trick? I would like full_name but no email to be displayed

[Ryan J Ollos <ryano@…>]

Replying to anonymous:

am i missing a configuration trick? I would like full_name but no email to be displayed

I'm not entirely sure these will have an effect in this case, but you should probably make sure your users don't have the EMAIL_VIEW permission, and that never_obfuscate_mailto is True.

[jaz]

how about patch for 1.0 dev version? I have created one for 0.13 . I'd work on 1.0 but have no access to svn…

[rainer.hihn@…]

Extended Patch to sort Full Names alphabetically

[rainer.hihn@…]

Replying to Hans-Peter Locher <locher.hanspeter@…>:

attachment:Trac-show_full_names-r4-0.12.2.patch​

I extended the patch so that the Options in the <select> are sorted alphabetically by their Full Names.

http://trac.edgewall.org/attachment/ticket/7339/Trac-show_full_names-sorted-r4-0.12.2.patch

[Chris.Nelson@…]

Replying to jaz:

how about patch for 1.0 dev version? I have created one for 0.13 . I'd work on 1.0 but have no access to svn…

How about just rolling this into the core? Is it controversial?

[cboos]

Last patch looks worth testing, but it would need to be ported to at least 1.0-stable first. If so, we'll review it more closely, test it (from the comments, I'm not sure if the problem mentioned in comment:52 was addressed), and it could possibly make it for 1.0.2.

[djones@…]

The -sorted version is very welcome, since our userids to not sort in the same order as last names.

Would love to see this rolled to core. I am planning to move from 0.12 to 1.0, but do not want to lose the real-names functionality.