On Tue, 2006-01-17 at 17:55 -0600, Brad Anderson wrote: > I have a patch on http://projects.edgewall.com/trac/ticket/2456 for > this functionality. It's a bit dated from > the trunk, but I think its purpose is still clear. > > I'm looking for feedback - I have basically just implemented what Trac > already did in the past, just now it's a > plugin. I have some questions and an example here: > http://trac.dsource.org/projects/test/wiki/UserDirectory
Well, it looks like the "get_known_user_info" method tries to stick to the current "get_known_users" API, though returning tuples is not going to support the flexibility needed to support new user attributes. User attributes should probably provided as a dictionary instead so that new attributes can be supported. Rather than passing the attribute names to "get_user_attribute" I think it'd be simpler to provide a method that returns a dictionary of the known attributes for a single user. Is "get_supported_attributes" necessary? I'm not sure when it would be used, and some implementations may be able to store any user attributes, so this may not be a static list of values. The Trac session is probably going to be the default storage for user attributes, and it supports any key/value pairs for attributes, so there's not limitation on what attributes it would support. I think that in designing this API we need to take into account other plugin needs related to user accounts. For example the IPasswordStore interface I wrote for the AccountManager plugin provides a method to get the list of known usernames. With something like LDAP the user accounts and settings are all coming from the same source, but if you're using "htdigest" for authentication and the Trac session for storing settings, the digest file is going to be the more definitive list of user accounts than the session information. I think that form-based logins is scheduled for 0.11, so we'll need to work out the relationship between account info for authentication and account info for users' settings. What about saving settings? If the mechanism supports it the "Settings" page should be able to update the users' settings. If I remember from some of the earlier discussions, the "limit" parameter on some of the methods is to limit the # of users listed when "restrict_owner" is turned on, however I'm not sure how this can be done in a meaningful manner. Displaying the first 10 of 100 users alphabetically is not very useful since there's a good chance the user you want to assign the ticket to is not in that list. If something like this is necessary maybe it should be provided through a separate API that would allow getting the users that have a particular permission. -- Matthew Good <[EMAIL PROTECTED]> _______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
