Embed some user information in TracWiki

[Steffen Hoffmann]

Sometimes it could be useful to show dynamically updated information about accounts/users.

Use case

Regular users can create and edit wiki pages, but not move or delete them. Wiki front page should hold the list of supervisors (users with WIKI_DELETE and WIKI_RENAME permission) to ask for help. Ideally the user list should be self-updating, so a WikiMacro could help, that queries the Trac db for accounts/users, like i.e. TicketQuery does for tickets.

[Steffen Hoffmann]

(In [11327]) AccountManagerPlugin: Introduce WikiMacros for AcctMgr, refs #9506 and #9852.

[Steffen Hoffmann]

For now this is more then I envisioned initially.

But if someone finds this useful too, maybe we'll see even more features to implement. I.e. UserManagerPlugin functionality, which includes wiki macros, could be incorporated this way.

[Ryan J Ollos]

I updated my install to r11327 and tried out the macro. It looks very useful. One small suggestion would be to specify that the locked key takes on true/false values, which I assume is the case but can't be sure since I don't have any locked users on my system.

Some of the features of UserStatsMacro could be useful too. Unfortunately that macro is GPL licensed so we probably can't use the code directly. I question how useful that would be anyway since the code is so simple to write, but if you think it would be helpful at all we can follow-up with pedro. He recently added the GPL license after I opened ticket #9806. He might be open to changing that to a BSD license.

I added a comment to the UserStatsMacro page that says that the AccountManagerPlugin has similar features since r11327.

[Steffen Hoffmann]

Replying to rjollos:

I updated my install to r11327 and tried out the macro. It looks very useful. One small suggestion would be to specify that the locked key takes on true/false values, which I assume is the case but can't be sure since I don't have any locked users on my system.

You speak about clarification of the macro description? Easy:

[[UserQuery(locked=1,nomatch=''No accounts locked'')]]

will give you the specified message then. But sure, expected values are not explicit right now. Should have done better, only was too much biased towards short explanations. Actually the macro looks for a valid True value (one of 'True', 'yes', '1') with case-insensitive matching. Everything else will be interpreted as locked='False'. Should it possibly be the other way-round and the False value required instead?

Some of the features of UserStatsMacro could be useful too. Unfortunately that macro is GPL licensed so we probably can't use the code directly. I question how useful that would be anyway since the code is so simple to write, but if you think it would be helpful at all we can follow-up with pedro. He recently added the GPL license after I opened ticket #9806. He might be open to changing that to a BSD license.

Thanks for the pointer. As stated above I've only thought towards UserManagerPlugin before.

I added a comment to the UserStatsMacro page that says that the AccountManagerPlugin has similar features since r11327.

Thoughtful indeed, thank you, especially for the early review.

[Steffen Hoffmann]

Just read the wiki page and pending tickets.

Actually I've been thinking about a last-login list, but trashed it. Obviously there is demand for such a feature.

I'll definitely adopt the idea. No need to try to incorporate code, because I'll take the direct way using a sufficiently flexible Genshi template. I'm sure, learning from ticket for GPL-ed software doesn't make the resulting code tied to GPL, right?

Development plan:

• add visit parameter and another valid format value table too
• add ignore_before
• i18n support for column headers
• "user time support" (trac-0.13dev), that is absolute/relative time interval display configurable per user
• finally provide UserStats too as wrapper calling UserQuery with argument translation, i.e. [[UserStats()]] --> [[UserQuery(visit)]]]

The existing ability to show full names and (properly obfuscated) emails comes in handy here (#4379). I like the colorize-by-time idea (#4238), and I guess it's not so complicated here with the Genshi template approach. Finally #4239 makes me think about proper arrangement with TracUserPagePlugin and TracMyPagePlugin, that both seem useful and link in nicely, but seem rather unmaintained (i.e. see #4888 and #8273).

Looks like a much bigger task than I intended by now, but maybe still worth the effort. What do you think? After all you've been the only one to care for both aforementioned plugins in a while.

[Steffen Hoffmann]

Btw, WikiStatsPlugin seems related too, because

[[UserCount]] from WikiStats is essentially the same as
[[UserQuery(count)]].

I see that you applied for maintainer-ship lately, so we may be able co-operate again on this subject, would be nice.

[Steffen Hoffmann]

I've created AccountManagerPlugin/WikiMacros for further discussion and tracking of WikiMacros development for this plugin.

[Steffen Hoffmann]

(In [11331]) AccountManagerPlugin: Improve macro description, add different locked parameter, refs #9852.

Recognition of the identically named non-keyed parameter allows for a shorter, still unambiguous notation.

[Ryan J Ollos]

Replying to hasienda:

Everything else will be interpreted as locked='False'. Should it possibly be the other way-round and the False value required instead?

I think the existing syntax is more clear. Another option would be to change it from a kwarg to a regular arg, and name it showlocked.

[Ryan J Ollos]

Replying to rjollos:

Another option would be to change it from a kwarg to a regular arg, and name it showlocked.

Oh, I see now you did something similar in [11331].

[Ryan J Ollos]

Replying to hasienda:

I'll definitely adopt the idea. No need to try to incorporate code, because I'll take the direct way using a sufficiently flexible Genshi template. I'm sure, learning from ticket for GPL-ed software doesn't make the resulting code tied to GPL, right?

I certainly can't provide an expert opinion, but after looking at the source code and thinking of your comment about how we'd rewrite this properly using Genshi, I agree that the UserQuery code will be significantly different than the original UserStatsMacro code. WikiStatsPlugin is fortunately BSD licensed, so no issues that I can see there.

Looks like a much bigger task than I intended by now, but maybe still worth the effort. What do you think? After all you've been the only one to care for both aforementioned plugins in a while.

I definitely think it is worth the effort to incorporate the features of UserStatsMacro and WikiStatsPlugin. I'd help with that over the coming weeks, with the aim of deprecating those and having them as part of AccountManagerPlugin.

I've used TracUserPagePlugin and TracMyPagePlugin since almost the day they were released and never encountered any issues. I generally try to take over maintainership of unmaintained plugins that I'm using, particularly when an issue arises and I want to push my patch and the author is no longer around. I could see doing some work on those eventually myself but those are a little way down my very long priority list ;)

[Steffen Hoffmann]

(In [11344]) AccountManagerPlugin: Split data processing and admin panel template, refs #9852.

[Steffen Hoffmann]

(In [11345]) AccountManagerPlugin: Provide user statistics similar to UserStatsMacro and more, refs #6616 and #9852.

UserQuery parameters 'email' and 'name' will add corresponding columns to the result table.

format_author is used to ensure email address obfuscation for web-UI persistence matching Trac core behavior.

The user query link is currently not implemented similar to UserStatsMacro, but users with `ACCTMGR_USER_ADMIN permission will see links to user details instead, like in recent version of the user admin panel.

[Steffen Hoffmann]

(In [11346]) AccountManagerPlugin: Add flexible date/time rendering for user lists, refs #6616 and #9852.

Now the time stamps are combined with a relative time interval hint (tool-tip). This is an enhancement to the user admin panel too.

Support for bleeding-edge user configurable time in Trac 0.13 is accompanied here by a fallback for Trac 0.11 and 0.12, that looks great and is worth a lot of the effort put into this rather complicated fallback code.

[Steffen Hoffmann]

(In [11347]) AccountManagerPlugin: Don't give away account/user details without elevated permission, refs #6616 and #9852.

USER_VIEW permission is required, where anonymous users could learn about sensitive information like existing accounts/users. This permission shouldn't be granted lightly in publicly available Trac applications, because it has the potential to encourage efficient brute-force attacks without the need to guess existing accounts.

[Steffen Hoffmann]

(In [11348]) AccountManagerPlugin: Update embedded macro description, refs #9852.

[Steffen Hoffmann]

(In [11349]) AccountManagerPlugin: Restore 0.11 compatibility, refs #6616, #9506 and #9852.

Use of user_time (from Trac 0.13) defeated the value of the compat function. The syntax for inheritance of USER_VIEW by ACCTMGR_USER_ADMIN is corrected, and finally ACCTMGR_USER_ADMIN now inherits EMAIL_VIEW from Trac core too, because setting user properties without seeing them by default felt wrong.

[Steffen Hoffmann]

(In [11350]) AccountManagerPlugin: Reimplement PageCount from WikiStatsPlugin, refs #9852.

Because this is a rather special macro I decided to include the functionality in Stats wiki macro by using keyed parameters. Added bonus is an optional prefix key to only include pages with matching names.

If it seens preferable to retain the original macro as a short-hand, this could still be done by adding it later on and treat it as an alias internally.

[Steffen Hoffmann]

(In [11364]) AccountManagerPlugin: Assign better name to statistics macro, refs #9852.

Stats goes ProjectStats following Ryan's suggestion.

[Steffen Hoffmann]

The easy stuff is done now regarding use of the strengths of this plugin.

But it's not final by no means. Some improvements and extensions will enter the source, when their time has come, probably tracked by another development ticket. As I wrote to the WikiMacros documentation page for AcctMgr I'll work on TracStatsPlugin for a while rather then spending more time for going into an exhaustive re-invention of Trac db harvesting for all sorts of statistical data here.

[Ryan J Ollos]

Replying to hasienda:

Stats goes ProjectStats following Ryan's suggestion.

I tend to think that is the best way to go, but don't get me wrong, I think that there are two very legitimate paths to take on this:

• Add ProjectStats and keep Stats as an alias for backward compatibility. With this approach, users will need to disable the WikiStatsPlugin when they enable the WikiMacros component of the AccountManagerPlugin. Another consideration is that in the case of a macro with an alias, Trac 0.12 will display a single entry on the WikiMacros page, but Trac 0.11.7 and earlier will show a separate entry for each macro with duplication of the documentation (see #5713 and ​t:#8782).
• Switch to ProjectStats for the AccountManagerPlugin, allowing the implementation in the AccountManagerPlugin to forget about backwards compatibility, and existing users can keep the WikiStatsPlugin installed. Of course, if we do preserve backwards compatibility in the calling syntax despite the name change, then a plugin like WikiReplacePlugin would support a mass-replace of Stats with ProjectStats, which is another worthwhile consideration.

Anyway, personally, I would leave as is, but if anyone gives pushback or there are other opinions on this, I think it's worth reconsidering.

[Ryan J Ollos]

What is the scope of the macros that you'd like to include with AccountManagerPlugin? Specifically, do you think the functionality of WikinfoPlugin would be a good fit?

[Steffen Hoffmann]

Note: See #3874 for how not to approach per-user and other elaborated statistics.

[Steffen Hoffmann]

Replying to rjollos:

What is the scope of the macros that you'd like to include with AccountManagerPlugin? Specifically, do you think the functionality of WikinfoPlugin would be a good fit?

User-related information is the major interest with AccountManager. WikinfoPlugin would better fit in TracStatsPlugin. I've already done much for i18n support of TracStatsPlugin, so suggesting more changes is just a follow-up. The author seems open-minded, so I'd give it a try. Consolidation in mind I'd aim at pushing the !Wikinfo macro into the TracStats suite, probably with a more Trac-like name WikiInfo.

[Ryan J Ollos]

Yeah, I'm with you on all these points. I've started a little project for myself that aims to be a collection of macros for retrieving info about milestones, tickets, files from repository, Ticket Version, Ticket Components, etc ... Basically, every macro that I'd wish they'd included in Trac and which doesn't depend on any other packages (e.g. PlantUmlMacro wouldn't be a candidate for inclusion).

I'd hoped to publish it at some point and consolidate a number of macros. Putting it in TracStatsPlugin is an interesting idea. With the aim of consolidating a half dozen existing macros, I even thinking the project could stand on its own, as a WikiMacrosPlugin or MoreWikiMacrosPlugin. To name just a few macros, the plugin would consolidate functionality in PlannedMilestonesMacro, WikinfoPlugin, ChangeLogMacro, CodeExampleMacro and possibly even IncludeMacro, in a slightly different form.

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