Edgewall Software
Modify

Opened 6 years ago

Last modified 13 days ago

#7339 assigned enhancement

[Patch] Display full user names instead of user login

Reported by: michael.grundberg@… Owned by: rjollos
Priority: high Milestone: 1.1.3
Component: general Version: 0.11.5
Severity: normal Keywords: username user review
Cc: mian.hasan.khalil@…, itamarost@…, thijstriemstra, macke@…, osimons, shoffmann, leho@…, martin.prikryl@…, franz.mayer@…, sterkrig@…, locher.hanspeter@…, boris.savelev@…, benco@…, djones@…, arkinform@…, ober.sebastian@…, fcorreia@…, rjollos, trac@…, jared.bownds@…, tadas.kazlauskas@…, jomae
Release Notes:
API Changes:

Description

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.

Attachments (12)

trac-show_full_names.diff (4.0 KB) - added by michael.grundberg@… 6 years ago.
trac-show_full_names-r2-0.11.5.diff (6.3 KB) - added by Matthew Caron <Matt.Caron@…> 5 years ago.
Show full names rev 2. (against trac 0.11.5)
trac-show_full_names-r3-0.11.5.diff (8.5 KB) - added by Hasan Khalil <mian.hasan.khalil@…> 5 years ago.
Show full names revision 3.
trac-show_full_names-r4-0.11.6.patch (9.4 KB) - added by Vaclav Slavik <vslavik@…> 5 years ago.
trac-show_full_names-r0-0.12b1.diff (7.4 KB) - added by KlauX 4 years ago.
Patch for Trac 0.12b1
Trac-show_full_names-r1-0.12.diff (7.7 KB) - added by KlauX <klaux1@…> 4 years ago.
Revision 1 plus alterations…
Trac-show_full_names-r1-0.12.2.diff (7.5 KB) - added by KlauX <klaux1@…> 4 years ago.
Revision 1 plus alterations…
Trac-show_full_names-r2-0.12.2.patch (12.5 KB) - added by Poly <polyflor@…> 4 years ago.
Repaired, tested and enhanced patch for 0.12.2
Trac-show_full_names-r3-0.12.2.patch (12.1 KB) - added by Poly <polyflor@…> 4 years ago.
interim patch (rev3) for 0.12.2
Trac-show_full_names-r4-0.12.2.patch (14.4 KB) - added by Hans-Peter Locher <locher.hanspeter@…> 3 years ago.
improved (rev3 + invalidation of cached known_users) patch for 0.12.2
Trac-show_full_names-sorted-r4-0.12.2.patch (14.4 KB) - added by rainer.hihn@… 23 months ago.
Extended Patch to sort Full Names alphabetically
Trac-show_full_names-sorted-r4-1.0.1.diff (14.9 KB) - added by markus.koechy@… 5 months ago.

Download all attachments as: .zip

Change History (111)

Changed 6 years ago by michael.grundberg@…

comment:1 Changed 6 years ago by ebray <hyugaricdeau@…>

I'm definitely +1 for this.

comment:2 Changed 6 years ago by anonymous

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

comment:3 follow-ups: Changed 6 years ago by cboos

  • Keywords username added
  • Milestone set to 0.13
  • Owner jonas deleted

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.

comment:4 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by 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…

comment:6 Changed 5 years ago by 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).

comment:7 Changed 5 years ago by dserodio@…

  • Cc dserodio@… added

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

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

comment:8 Changed 5 years ago by 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.

Changed 5 years ago by Matthew Caron <Matt.Caron@…>

Show full names rev 2. (against trac 0.11.5)

comment:9 Changed 5 years ago by mian.hasan.khalil@…

  • Cc mian.hasan.khalil@… added

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

Changed 5 years ago by Hasan Khalil <mian.hasan.khalil@…>

Show full names revision 3.

comment:10 Changed 5 years ago by 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.

comment:11 in reply to: ↑ 3 ; follow-up: Changed 5 years ago by Hasan Khalil <mian.hasan.khalil@…>

  • Version changed from 0.11rc2 to 0.11.5

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.

comment:12 Changed 5 years ago by Vaclav Slavik <vslavik@…>

  • Cc vslavik@… added

comment:13 in reply to: ↑ 11 ; follow-up: Changed 5 years ago by 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.

comment:14 in reply to: ↑ 13 Changed 5 years ago by 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.

Changed 5 years ago by Vaclav Slavik <vslavik@…>

comment:15 follow-up: Changed 5 years ago by 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.

comment:16 Changed 5 years ago by cboos

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

Changed 4 years ago by KlauX

Patch for Trac 0.12b1

comment:17 in reply to: ↑ 15 Changed 4 years ago by 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?

Changed 4 years ago by KlauX <klaux1@…>

Revision 1 plus alterations…

Changed 4 years ago by KlauX <klaux1@…>

Revision 1 plus alterations…

comment:18 Changed 4 years ago by cboos

  • Keywords review added

comment:19 Changed 4 years ago by itamaro

  • Cc itamarost@… added
  • Keywords user added

comment:20 Changed 4 years ago by lkraav <leho@…>

  • Cc leho@… added

comment:21 Changed 4 years ago by alexander.papaspyrou@…

  • Cc alexander.papaspyrou@… added

comment:22 Changed 4 years ago by thijstriemstra

  • Cc thijstriemstra added

Patch needs a review.

comment:23 Changed 4 years ago by thijstriemstra

  • Priority changed from normal to high

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

comment:24 Changed 4 years ago by Marcus Lindblom <macke@…>

  • Cc macke@… added

comment:25 Changed 4 years ago by ajax

This patch doesnt work with TRAC 0.12.2rc1

comment:26 Changed 4 years ago by 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.

comment:27 Changed 4 years ago by Poly <polyflor@…>

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

Changed 4 years ago by Poly <polyflor@…>

Repaired, tested and enhanced patch for 0.12.2

comment:28 Changed 4 years ago by 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.

comment:29 follow-up: Changed 4 years ago by 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:
  • 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)

comment:30 Changed 4 years ago by osimons

  • Cc osimons added

comment:31 Changed 4 years ago by shoffmann

  • Cc shoffmann added

Changed 4 years ago by Poly <polyflor@…>

interim patch (rev3) for 0.12.2

comment:32 in reply to: ↑ 29 Changed 4 years ago by 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!

comment:33 Changed 3 years ago by lkraav <leho@…>

  • Cc leho@… removed

comment:34 Changed 3 years ago by lkraav <leho@…>

  • Cc leho@… added

comment:35 Changed 3 years ago by taylor@…

  • Cc taylor@… added

comment:36 Changed 3 years ago by Martin Přikryl <martin.prikryl@…>

  • Cc martin.prikryl@… added

comment:37 Changed 3 years ago by Anton Bobov <bobov_a@…>

  • Cc bobov_a@… added

comment:38 Changed 3 years ago by haircut@…

  • Cc haircut@… added

comment:39 Changed 3 years ago by framay <franz.mayer@…>

  • Cc franz.mayer@… added

comment:40 Changed 3 years ago by krigstask <sterkrig@…>

  • Cc sterkrig@… added

comment:41 Changed 3 years ago by dserodio@…

  • Cc dserodio@… removed

comment:42 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by 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.

comment:43 in reply to: ↑ 42 Changed 3 years ago by 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 :>

Changed 3 years ago by Hans-Peter Locher <locher.hanspeter@…>

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

comment:44 follow-ups: Changed 3 years ago by 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

comment:45 in reply to: ↑ 44 ; follow-up: Changed 3 years ago by Hans-Peter Locher <locher.hanspeter@…>

comment:46 Changed 3 years ago by Hans-Peter Locher <locher.hanspeter@…>

  • Cc locher.hanspeter@… added

comment:47 Changed 3 years ago by 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?

comment:48 Changed 3 years ago by Boris Savelev <boris.savelev@…>

  • Cc boris.savelev@… added

comment:49 Changed 2 years ago by 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?

comment:50 Changed 2 years ago by anonymous

Patch works for 0.12.3, too :).

comment:51 Changed 2 years ago by Ryan J Ollos <ryano@…>

  • Cc ryano@… added

comment:52 in reply to: ↑ 44 ; follow-up: Changed 2 years ago by 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

Last edited 9 months ago by rjollos (previous) (diff)

comment:53 in reply to: ↑ 52 Changed 2 years ago by 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.

comment:54 follow-up: Changed 2 years ago by 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…

comment:55 Changed 2 years ago by benco@…

  • Cc benco@… added

Changed 23 months ago by rainer.hihn@…

Extended Patch to sort Full Names alphabetically

comment:56 in reply to: ↑ 45 Changed 23 months ago by 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

comment:57 in reply to: ↑ 54 Changed 23 months ago by 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?

comment:58 Changed 23 months ago by 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.

comment:59 Changed 22 months ago by djones@…

  • Cc djones@… added

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.

comment:60 Changed 22 months ago by alexander.papaspyrou@…

  • Cc alexander.papaspyrou@… added

comment:61 Changed 22 months ago by alexander.papaspyrou@…

  • Cc alexander.papaspyrou@… removed

comment:62 Changed 22 months ago by alexander.papaspyrou@…

  • Cc alexander.papaspyrou@… removed

comment:63 Changed 22 months ago by arkinform@…

  • Cc arkinform@… added

comment:64 Changed 22 months ago by haircut@…

  • Cc haircut@… removed

comment:65 Changed 21 months ago by ober.sebastian@…

  • Cc ober.sebastian@… added

comment:66 Changed 21 months ago by fcorreia@…

  • Cc fcorreia@… added

comment:67 Changed 18 months ago by trac@…

  • Cc trac@… added

comment:68 Changed 13 months ago by Jaredbownds

Are there any plans to support 1.0 with this feature?

comment:69 Changed 12 months ago by rjollos

  • Cc rjollos added

comment:70 Changed 12 months ago by rjollos

  • Cc ryano@… removed

comment:71 Changed 12 months ago by anonymous

Is there any movement on this for 1.0?

comment:72 Changed 12 months ago by trac@…

  • Cc trac@… added

comment:73 Changed 10 months ago by Nikolaj Sjujskij <skrattaren@…>

  • Cc skrattaren@… added

comment:74 Changed 9 months ago by anonymous

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

comment:75 Changed 8 months ago by Chris.Nelson@…

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

comment:76 Changed 8 months ago by anonymous

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

comment:77 Changed 6 months ago by anonymous

Anything new here ? we want this in 1.0.1 also.

comment:78 Changed 6 months ago by rjollos

  • Milestone changed from next-major-releases to 1.1.3

We can try to include this in 1.1.3.

Changed 5 months ago by markus.koechy@…

comment:79 Changed 5 months ago by 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

comment:80 follow-up: Changed 5 months ago by rjollos

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

comment:81 in reply to: ↑ 80 Changed 5 months ago by psuter

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.

comment:82 Changed 5 months ago by rjollos

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.

comment:83 Changed 4 months ago by taylor@…

  • Cc taylor@… removed

comment:84 Changed 4 months ago by Jared Bownds <jared.bownds@…>

  • Cc jared.bownds@… added

I too am interested in this patch.

comment:85 Changed 4 months ago by Jared Bownds <jared.bownds@…>

Are there any new updated on this patch?

comment:86 Changed 4 months ago by tadas.kazlauskas@…

Interested to get it fixed too.

comment:87 Changed 4 months ago by Tadas Kazlauskas <tadas.kazlauskas@…>

  • Cc tadas.kazlauskas@… added

comment:88 Changed 4 months ago by trac@…

  • Cc trac@… removed

comment:89 Changed 3 months ago by anonymous

+1

known_users really needs to be cached

comment:90 Changed 3 months ago by 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

comment:91 follow-up: Changed 3 months ago by 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.

comment:92 follow-up: Changed 3 months ago by 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.

comment:93 Changed 3 months ago by jomae

  • Cc jomae added

comment:94 Changed 3 months ago by bobov_a@…

  • Cc bobov_a@… removed

comment:95 Changed 3 months ago by vslavik@…

  • Cc vslavik@… removed

comment:96 in reply to: ↑ 91 Changed 3 months ago by 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.

comment:97 Changed 3 weeks ago by rjollos

  • Owner set to rjollos
  • Status changed from new to assigned

comment:98 in reply to: ↑ 92 Changed 2 weeks ago by 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!

Last edited 13 days ago by rjollos (previous) (diff)

comment:99 Changed 2 weeks ago by skrattaren@…

  • Cc skrattaren@… removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as assigned The owner will remain rjollos.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from rjollos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.