Did something similar just for cvs, maybe related.

[git.ikiwiki.info.git] / doc / todo / Separate_OpenIDs_and_usernames.mdwn

diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index 3fb952f965bccf6259aab99f6d95b88516fc85d4..b7ff82282ed04078907ef889a14538004c6b6cd5 100644 (file)
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -13,21 +13,43 @@ A slightly more complex next step would be to request sreg from the provider and
 > implemented as a badly-done wart on the side of their regular login
 > system.
 > 
 > implemented as a badly-done wart on the side of their regular login
 > system.
 > 

+> > If there are user profiles on the site with non-empty information associated with them (including permissions, reputation), then it would make more sense to be able to access your user profile with alternative OpenIDs (in case one of the provider goes down), as on <http://stackoverflow.com>. In ikiwiki, there might be no such special information associated with users (or you can think of something like this?), except for the admin rights. But fortunately, several OpenIDs can be set up for admins in ikwiki. (Only if it comes to [the OpenIDs provided by Gmail][forum/google openid broken?], then it turns out to be unhandy to write the ID into the configuration file as a second admin ID.)--Ivan Z.
+> 

 > The openid plugin now attempts to get an email and a username, and stores
 > them in the session database for later use (ie, when the user edits a
 > page).
 > 
 > I am considering displaying the userid or fullname, if available,
 > The openid plugin now attempts to get an email and a username, and stores
 > them in the session database for later use (ie, when the user edits a
 > page).
 > 
 > I am considering displaying the userid or fullname, if available,

-> instead of the munged openid url in recentchanges. It would be nice
-> for those nasty [[google_openids|forum/google_openid_broken?]]. But,
-> I first have to find a way to encode the name in the VCS commit log,
+> instead of the munged openid url in recentchanges and comments.
+> It would be nice for those nasty [[google_openids|forum/google_openid_broken?]].
+> But, I first have to find a way to encode the name in the VCS commit log,

 > while still keeping the openid of the committer in there too.
 > Perhaps something like this (for git): --[[Joey]] 
 > 
 >      Author: Joey Hess &lt;http://joey.kitenet.net/@web&gt;
 > 
 > while still keeping the openid of the committer in there too.
 > Perhaps something like this (for git): --[[Joey]] 
 > 
 >      Author: Joey Hess &lt;http://joey.kitenet.net/@web&gt;
 > 

+> Only problem with the above is that the openid will still be displayed
+> by CIA. Other option is this, which solves that, but at the expense of
+> having to munge the username to fit inside the email address,
+> and generally seems backwards: --[[Joey]] 
+> 
+>      Author: http://joey.kitenet.net/ &lt;Joey_Hess@web&gt;
+> 
+> So, what needs to be done:

 > 
 > 

+> * Change `rcs_commit` and `rcs_commit_staged` to take a session object,
+>   instead of just a userid. (For back-compat, if the parameter is 
+>   not an object, it's a userid.) Bump ikiwiki plugin interface version.
+>   (done)
+> * Modify all RCS plugins to include the session username somewhere
+>   in the commit, and parse it back out in `rcs_recentchanges`.
+>   (done for git only so far)
+> * Modify recentchanges plugin to display the username instead of the
+>   `openiduser`.
+>   (done)
+> * Modify comment plugin to put the session username in the comment
+>   template instead of the `openiduser`. (done)

 
 Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
 
 
 Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
 

-[[!tag wishlist]]
+[[!tag wishlist done]]