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

[Christian Boos]

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.

[Christian Boos]

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…

[Christian Boos]

#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​.

[Christian Boos]

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.

[Christian Boos]

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: […]

This patch is upside down?

[KlauX <klaux1@…>]

Revision 1 plus alterations…

[KlauX <klaux1@…>]

Revision 1 plus alterations…

[Thijs Triemstra]

Patch needs a review.

[Thijs Triemstra]

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.

[Christian Boos]

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?

[Christian Boos]

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.

[Jaredbownds]

Are there any plans to support 1.0 with this feature?

[anonymous]

Is there any movement on this for 1.0?

[anonymous]

I would really like to use this with my Trac 1.0.1 setup, is this possible?

[Chris.Nelson@…]

I have a patch to 1.0.1. I'm surprised this has never been put into core.

[anonymous]

I would also love to use this on 1.0.1. What's the recommended approach here?

[anonymous]

Anything new here ? we want this in 1.0.1 also.

[Ryan J Ollos]

We can try to include this in 1.1.3.

[markus.koechy@…]

I applied the patch attachment:Trac-show_full_names-sorted-r4-0.12.2.patch​ to Trac 1.0.1 by hand and this is the resulting patch: attachment:Trac-show_full_names-sorted-r4-1.0.1.diff​​

[Ryan J Ollos]

The patch from comment:79 applied somewhat cleanly to the trunk: log:rjollos.git:t7339.

[Peter Suter]

Replying to rjollos:

The patch from comment:79 applied somewhat cleanly to the trunk:

There seem to be some problems in this patch:

• x['label'] == 'Owner' only works for English.
  • Consider moving that sort-by-name logic into _prepare_fields after field['label'] = _("Owner")?
  • Or maybe even into TicketSystem.eventually_restrict_owner()?
• operator.itemgetter(1)(v) sorts by the second letter in the name(?) (or throws if the name is too short for that)
  • Assuming we just want to sort by the result of format_author(), that entire block of code could be replaced by x['options'] = sorted(x['options'], key=partial(chrome.format_author, req))
• The logic tests combining show_email_addresses and EMAIL_VIEW look wrong.
• Cache invalidation might be required in _do_delete and promote_session?
• …

log:rjollos.git:t7339.

I think you forgot to actually rename the definition of Chrome.invalidate_known_users() to Chrome.reset_known_users().

I would move that and the known_users cache to Environment instead, where we already have get_known_users()​. And perhaps turn it around so the cached property _known_users is used locally in that method, similar to _all_permissions​.

[Ryan J Ollos]

Thanks for the suggestions. I didn't mean to imply that I thought the patch was ready. It'll be a few more weeks before I get to working on it so if anyone else want to move forward please feel free.

[Jared Bownds <jared.bownds@…>]

I too am interested in this patch.

[Jared Bownds <jared.bownds@…>]

Are there any new updated on this patch?

[tadas.kazlauskas@…]

Interested to get it fixed too.

[anonymous]

+1

known_users really needs to be cached

[Jared Bownds <jared.bownds@…>]

It would be good to have a timeline expectation for this patch. Implementing this ability will dramatically increase the adoption rate of Trac in large environments.

As an alternative, perhaps it's easier to display a users email address? Most times email addresses are more meaningful than a user name. Although, it sounds like the same mechanics may be involved.

Please let me know if you need my assistance with testing and feedback.

Best, Jared

[Ryan J Ollos]

The timeline is a few months to get it on the trunk, then a preview development release to follow (milestone:1.1.3) and then finally it will be in a production-stable release, Trac 1.2, which will be released sometime next year I imagine. When one of the developers has time to work on it you will see activity in this ticket. All of the devs are volunteers on this project, and while we want to make Trac the most magnificent issue tracker in the world (and someday it will be), for the moment the reality of our day jobs limits us to only the waking moments away from our day jobs. Anyone is welcome to work on this ticket to move it along, there was good feedback on what needs to be done in comment:81 (see PatchWelcome and ThisTicketWasOpenedTenYearsAgo, and understand that the patch in this ticket needs to be improved). Thank you for your offer to test.

If you wish to show email addresses, you can try the show_email_addresses option in the [trac] section of trac.ini [TracIni#trac-section]. It may do what you want. I'm unsure.

[Ryan J Ollos]

I see that Jun has posted a plugin just this week, ​th:UsernameDecoratePlugin, which implements this feature. Hopefully that will hold everyone over until this ticket is resolved.

[Jared Bownds <jared.bownds@…>]

Replying to rjollos:

The timeline is a few months to get it on the trunk, then a preview development release to follow (milestone:1.1.3) and then finally it will be in a production-stable release, Trac 1.2, which will be released sometime next year I imagine. When one of the developers has time to work on it you will see activity in this ticket. All of the devs are volunteers on this project, and while we want to make Trac the most magnificent issue tracker in the world (and someday it will be), for the moment the reality of our day jobs limits us to only the waking moments away from our day jobs. Anyone is welcome to work on this ticket to move it along, there was good feedback on what needs to be done in comment:81 (see PatchWelcome and ThisTicketWasOpenedTenYearsAgo, and understand that the patch in this ticket needs to be improved). Thank you for your offer to test.

If you wish to show email addresses, you can try the show_email_addresses option in the [trac] section of trac.ini [TracIni#trac-section]. It may do what you want. I'm unsure.

Hi Ryan,

Thank you for your response. I do realize all the developers who contribute to this project do so on a volunteer basis, which is quite incredible. On the other hand, those who make the most noise typically receive the most attention, or maybe they get completely ignored!? At either rate, I appreciate you, and the the rest of the team who remain committed to improving Trac.

[anonymous]

Replying to rjollos:

I see that Jun has posted a plugin just this week, ​th:UsernameDecoratePlugin, which implements this feature. Hopefully that will hold everyone over until this ticket is resolved.

+1 for ​UsernameDecoratePlugin. It's a fairly small plugin without having to patch the Trac code. I tried the patch, but i prefer the way ​UsernameDecoratePlugin works from the UI perspective. I like the alt or pop-up hints. I think it's cleaner. Nice plugin!

[Ryan J Ollos]

Replying to anonymous:

+1

known_users really needs to be cached

This will be implemented in #11868.

[Ryan J Ollos]

Narrowing focus for 1.1.4.

[Ryan J Ollos]

Latest changes in log:rjollos.git:t7339.2. I haven't looked closely at these in many weeks. From what I remember, there was still a problem getting the user's full name displayed in the selects on the Query page.

[Ryan J Ollos]

Changes have been rebased now that #11474 is committed: log:rjollos.git:t7339.3. More work is needed, but I hope to have it done for milestone:1.2.

[Ryan J Ollos]

Text inputs, such as the owner query filter and owner workflow field (when [ticket] restrict_owner is False), require a username to be input. This could be a bit confusing, but could be mediated by adding typeahead (similar to ​th:AutocompletePlugin, see #7628). I welcome other suggestions for handling this.

[Ryan J Ollos]

Proposed changes in log:rjollos.git:t7339.5.

In the future I'll look into adding more features of ​UsernameDecoratePlugin, but for now I just want to make sure we get these changes included in milestone:1.2.

[Ryan J Ollos]

Committed to trunk in [14247:14248,14258].

[Ryan J Ollos]

Usernames need to be formatted in notification emails.

[Ryan J Ollos]

Replying to Ryan J Ollos:

Usernames need to be formatted in notification emails.

⇒ #12206.

[Ryan J Ollos]

Replying to Ryan J Ollos:

In the future I'll look into adding more features of ​UsernameDecoratePlugin, …

⇒ #12210

[Christian Boos]

See also ticket:12120#comment:10 for a minor glitch in the "group progress" panel.

[Ryan J Ollos]

Thanks, somehow I forgot to follow up on the issue. I'll look into the glitch shortly.

[Christian Boos]

Replying to Ryan J Ollos:

Thanks, somehow I forgot to follow up on the issue. I'll look into the glitch shortly.

In the Jinja2 branch, while converting the progress_bar_grouped.html template, I think I fixed it. See in [b0ddc4d5/cboos.git#file1], set obfuscated = format_author(group.name) != format_author(group.name, show_email=false). Is that correct?

[Ryan J Ollos]

Thanks for the hint, and sorry for the long delay. It appears the issue would be fixed with either of these changes:

• Option 1

  trac/templates/progress_bar_grouped.html

  @@ -21 +21 @@
         xmlns:i18n="http://genshi.edgewall.org/i18n"
         py:strip="">
     <table summary="${value_of('summary', None)}">
  -    <tr py:for="group in groups" py:with="obfuscated = format_author(group.name) != group.name;">
  +    <tr py:for="group in groups" py:with="obfuscated = format_author(group.name) != format_author(group.name, show_email=True);">
         <th scope="row" py:choose="">
           <i py:when="not group.name"><a href="${group.stats_href}">(none)</a></i>
           <a py:when="grouped_by in ['owner', 'reporter']"

• Option 2

  trac/templates/progress_bar_grouped.html

  @@ -21 +21 @@
         xmlns:i18n="http://genshi.edgewall.org/i18n"
         py:strip="">
     <table summary="${value_of('summary', None)}">
  -    <tr py:for="group in groups" py:with="obfuscated = format_author(group.name) != group.name;">
  +    <tr py:for="group in groups" py:with="obfuscated = is_obfuscated(format_author(group.name))">
         <th scope="row" py:choose="">
           <i py:when="not group.name"><a href="${group.stats_href}">(none)</a></i>
           <a py:when="grouped_by in ['owner', 'reporter']"

  trac/web/chrome.py

  @@ -50 +50 @@
   from trac.util import as_bool, as_int, compat, get_reporter_id, html,\
                         presentation, get_pkginfo, pathjoin, translation
   from trac.util.html import escape, plaintext
  -from trac.util.text import pretty_size, obfuscate_email_address, \
  -                           shorten_line, unicode_quote_plus, to_unicode, \
  -                           javascript_quote, exception_to_unicode, to_js_string
  +from trac.util.text import (
  +    exception_to_unicode, is_obfuscated, javascript_quote,
  +    obfuscate_email_address, pretty_size, shorten_line, to_js_string,
  +    to_unicode, unicode_quote_plus)
   from trac.util.datefmt import (
       pretty_timedelta, datetime_now, format_datetime, format_date, format_time,
       from_utimestamp, http_date, utc, get_date_format_jquery_ui, is_24_hours,
  @@ -615 +616 @@
           'group': presentation.group,
           'groupby': compat.py_groupby,  # http://bugs.python.org/issue2246
           'http_date': http_date,
  +        'is_obfuscated': is_obfuscated,
           'istext': presentation.istext,
           'javascript_quote': javascript_quote,
           'ngettext': translation.ngettext,

I tend to think the latter is more clear.

[Ryan J Ollos]

Proposed changes in log:rjollos.git:t7339_grouped_progress_bar.

[Christian Boos]

Ah, I missed the introduction of trac.util.text.is_obfuscated… nice! Yes, it's better that way.

[Ryan J Ollos]

comment:121 changes committed to trunk in [14683].

[Ryan J Ollos]

r15185 fixes sorting of user fullnames in workflow reassign action control.

[Ryan J Ollos]

#12593 is associated with this ticket.