[Patch] tf.who should be passed through format_author

[mattc]

When you have a "who" it would be nice to run that through format_author... especially if you've patched format_author to show the full name. ;-)

Patch attached.

[mattc]

Patch to macros.py to run the who through format_author.

[hasienda]

Replying to mattc:

When you have a "who" it would be nice to run that through format_author... especially if you've patched format_author to show the full name. ;-)

Sorry for the long time of support missing from here. Now I'm interested to bring this into trunk soon. Could I find that mod for format_author somewhere too?

[hasienda]

It took a while, until I actually looked into trac.web.chrome today, to understand the possibilities of that. But wait - the most relevant improvement, processing email addresses (with optional obfuscation) is not relevant here, as long as user<>email, right?

It's still nice to know where to start an improvement. But the problem is still how to get the full name without patching Trac directly (and consequently future versions over-and-over again), and I'll consider this incomplete, until this has been solved. Most likely copying Chrome from trac.web.chrome and adding what otherwise as to be patched to Trac is the way to go. Or (better) add that method to AccountManagerPlugin to make re-using it easier/more likely.

[anonymous]

Replying to hasienda:

Replying to mattc:

When you have a "who" it would be nice to run that through format_author... especially if you've patched format_author to show the full name. ;-)

Sorry for the long time of support missing from here. Now I'm interested to bring this into trunk soon. Could I find that mod for format_author somewhere too?

I had forgotten that I owed you this patch. I will try to get to it today.

[matt.caron@…]

Replying to hasienda:

It took a while, until I actually looked into trac.web.chrome today, to understand the possibilities of that. But wait - the most relevant improvement, processing email addresses (with optional obfuscation) is not relevant here, as long as user<>email, right?

Yes. This is only helpful if != email. The way we run it, everyone has a username (say, like "matt") and this is mapped to the full name you can put in in the preferences.

It's still nice to know where to start an improvement. But the problem is still how to get the full name without patching Trac directly (and consequently future versions over-and-over again), and I'll consider this incomplete, until this has been solved.

I solved it by tracking upstream Trac in git so I just merge in upstream changes to my code, fix conflicts and redeploy.

[hasienda]

There are a lot more occurrences of usernames after adding form view, so I'll look into this again and apply an extended patch even if there's no immediately profit for most applications where username != email.

[hasienda]

Just to confirm, that this is WiP:

But as I expected there is considerably more related work to be done. format_author() requires user information do any mapping. And sadly this is env.get_known_users() seems like a weak spot. It queries the Trac db again and again with a double JOIN LEFT, so this is quite costly with a large user base. So I went on to

1. make it configurable (default = disabled) for backwards compatibility too
2. add an optional user data cache to reduce the burden on the db, but this is feature is available only for Trac >= 0.12

A good thing about it: The functionality will be available _without_ patching Trac core. Thoughts?

[hasienda]

(In [10227]) TracFormsPlugin: Introduce a custom format_author(), refs #6033.

It adds not only email address obfuscation but configurable full username
display too. To enable this in all content provided by TracForms
you'll need to add a dedicated configuration to your trac.ini as follows:

[forms]
show_fullname = true
show_fullname_position = change,macro,value

Caching the query done in env.get_known_users() is really nice,
only the CacheManager is available since Trac revision 8071 (0.12dev).
So this is kept optional to maintain compatibility with Trac < 0.12 .

[hasienda]

No in-depended test feedback by now? This is a bit disappointing. Come-on, let's try it!

[hasienda]

My own Trac applications provided plenty of opportunities for testing this, working fine.