XMLRPC plugin needs an interface to get identifiable user information user.info()

[karladam@…]

Currrently when you query for a ticket's information you get all the attributes on it, however I have no way to identify a user uniquely besides their username which is only relevant on the server. So I can't contact that user through his email information or have a local application specific user store that can query this information for particular users. So if I had this interface I could get a user's full name(first and last), and at least his email. I assume the AccountManagerPlugin could extend the attributes available for a user and maybe even add more calls like a user.getAll()

[Alec Thomas]

This could be added to AccountManagerPlugin or perhaps user session introspection could be added to XmlRpcPlugin.

[osimons]

I have made a version that returns the env.get_known_users() call - customised for our particular setup in several ways, but very easy to implement in a straight forward fashion (untested example implementation):

def getKnownUsers(self, req):
    """ Docs :-) """
    return self.env.get_known_users()

It allows us implement 'assign-to' as a drop-down in a custom ticket form, for instance.

The implementation is very easy - the difficult part with this is actually determining permissions - what permission should be required to fetch this list? It has many possible uses, not just tickets. However, it is easy to see that data can very easily be abused with relaxed permissions in public projects.

This calls for some precautions, and my feeling is that user-related features need to be spread out across various modules, and highly tuned to specific tasks and permissions.

• An implementation for ticket.getKnownUsers() should perhaps just return the username for populating drop-downs (to assign), and perhaps only return data if the restrict config setting is enabled - and using corresponding ticket permissions.
• The full-list example above could perhaps require TRAC_ADMIN?
• An implementation for the AccountManagerPlugin to view and modify data belong in that plugin, and tuned to the needs and permissions of corresponding methods there (likely all TRAC_ADMIN).

[osimons]

Ah, just noticed #1010 that explicitly request the ticket.getKnownUsers()-like aspect of this.

As this ticket is somewhat ambiguous (potentially covering several plugins), I suggest:

• This ticket is moved to AccountManagerPlugin as a request for xmlrpc features added to that plugin.
• And, the ticket-drop-down-related part is continued in #1010 as a possible extension to standard XmlRpcPlugin.

[osimons]

XmlRpcPlugin as of [6045] provides workflow support, and if Trac is configured to include 'reassign' as as a drop-down (and permissions permits), the getActions() call will also include all valid users as options for the action. As Trac makes no futher use of a userlist, I don't see a reason for the XmlRpcPlugin to provide one either - if needed I'd rather that existed as a separate plugin extending available methods, either with AccountManagerPlugin or as a standalone feature pullig data from somewhere (as Trac itself does not have much useful user-related data).

I'm changing the component as I suggested some time ago.

[Steffen Hoffmann]

Osimons, you mentioned to me, that you actually don't use AccountManagerPlugin but an own solution. So is this task/request still valid?

I'm willing to make this happen, if you'd care to cooperate especially by joining discussion for implementation details and assist with testing, as I currently lack a test environment for Trac 0.10 and 0.11 .

[osimons]

Replying to hasienda:

Osimons, you mentioned to me, that you actually don't use AccountManagerPlugin but an own solution. So is this task/request still valid?

If any of your plugin data is intended for user consumption, then an API is a valid enhancement request. However, if all data is used by the user only (for authentication and communication) then letting other users inspect that data may not be ideal. You'd need to answer this yourself as I don't know the plugin.

I'm willing to make this happen, if you'd care to cooperate especially by joining discussion for implementation details and assist with testing, as I currently lack a test environment for Trac 0.10 and 0.11 .

Using an optional extras in setup.py you can make an 'rpc' module be optionally enabled depending on the XmlRpcPlugin being instaled. To get started with the XmlRpcPlugin in general (for 0.11 or 0.12), have a look at my recent blog post:

​https://www.coderesort.com/u/simon/blog/2010/09/23/tracrpc_development

I have abandoned Trac 0.10 development, so don't even ask...

[anonymous]

When I originally filed this ticket, it was because I was intending to write a desktop client that leveraged Trac. The problem of first needing an XML-RPC plugin was surmountable, but the secondary requirement of then installing a AccountManagerPlugin on top of that contributed to my having to eventually give that up. Serendipitously, I'm currently in the middle of development of a similar product that leverages github and has a similar task viewing capability as that which spawned this original request.

My hope for this ticket, is that Trac can gain some representation of users that is inherent to its implementation such that assigning and reassigning tickets, isn't a matter of typing in the email address explicitly, or building up a local user db from previously seen email addresses. Both approaches are inelegant since the email addresses are not guaranteed to be involved in a project outside of a single ticket, and any heuristics I can assemble will always have shortcomings compared to requesting a listing of all users officially associated with the project.

[osimons]

Replying to anonymous:

My hope for this ticket, is that Trac can gain some representation of users that is inherent to its implementation such that assigning and reassigning tickets, isn't a matter of typing in the email address explicitly, or building up a local user db from previously seen email addresses. Both approaches are inelegant since the email addresses are not guaranteed to be involved in a project outside of a single ticket, and any heuristics I can assemble will always have shortcomings compared to requesting a listing of all users officially associated with the project.

Right. Which is also why I for ​http://www.CodeResort.com have implemented my own alternative that is more in line with what I needed too:

• Users from permission list instead of session using some custom code to replace the Trac implementation so that RPC plugin will happily provide my alternative list of users for assigning to tickets and similar.
• RPC extensions such as array coderesort.getProjectMembers() that returns the current users known to the project (again user is someone with some explicit named permission).

Without core support for a full user-dimension in Trac, it makes no sense to add such support to the RPC plugin. Hence why I'm leaving this alone.

Anyway, good luck with your alternative product :-)

[Steffen Hoffmann]

Thanks for the fast and detailed feedback. I've visited CodeResort (I've to confess actually for the first time) for the blog and looked at the custom equivalents to /login /register and the 'lost password' page as well.

Using the email address for the UID is quite different from Trac core and AccountManagerPlugin following it by now. It enables you to provide arbitrary re-configurable nicknames, nice. Other things are more natural or even trivial and more like the extensions provided by UserManagerPlugin.

This issue reminds me of the evening when I discovered ​T#1942, that requested native support for true custom date/time fields for Trac without messing around with string manipulation. I couldn't understand, why no one had attempted to resolved this essential for project management outside of source code development for 4+ years. I feel quite the same now, seeing the pending request to make happen something like the following for such a long time as well:

mgr = AccountManager(self.env)
email_map = [mgr.user.get(email)]

print email_map
[{'user': 'u1', 'email': 'u1@foo.com'}, {'user': 'u2', 'email': 'u2@bar.com'}]

Is this more or less the thing you're interested in, or just a misunderstanding (if so, please provide a different example to make me get it)?

I'm still a Python newbie, and no one should expect to see a new revolutionary Trac user interface designed by me. Anyway, I'll leave this alone for a while only to think of possibilities to approach this. I know, a sane(r) user resource implementation is discussed (to death?) for Trac core as well, and as osimons pointed out, it might be really better to fix it there in the first place.