OpenWetWare talk:Software/User management

From OpenWetWare
Jump to navigationJump to search
  • Reshma 21:14, 14 January 2008 (CST): In watching new users who've come on since the auto-generation of user pages, I've noticed that there still seems to be some reluctance by new users to actually edit their own pages despite the message inviting them to do so. I wonder if we should instead populate people's user pages with an outline of a page e.g., the structure found at OpenWetWare:Getting started 2 for example. I think it is actually easier for people to edit a page with some structure and fill in the blanks etc. What do people think? We could try it for a while and see how it goes?
  • Reshma 21:14, 14 January 2008 (CST): Also, I don't remember ... which is the page to edit UserPageDefaultContentText or OpenWetWare:UserPageDefaultContentText? We should delete whichever one is not used.

Old Discussion

New Feature Requests

  • Sri Kosuri (talk) 15:07, 28 September 2007 (EDT): Great work on the new changes! Can we have the history listing be in chronological order starting from the most recent?
  • Sri Kosuri 11:01, 4 May 2006 (EDT): CC the admin list the email sent to a new user (whether rejected or not).
  • Sri Kosuri 11:01, 4 May 2006 (EDT): When editing the text of a letter, the button should say save changes (currently stays as edit this page).
  • Ilya 17:22, 1 May 2006 (EDT): Some time ago there was an idea of an OWW newsletter floating around. It may be useful to add a checkbox to the account request form that would allow user to choose whether they would like to be on that mailing list or not.
    • Austin 18:39, 1 May 2006 (EDT): In general for future extensibility, it'd be nice to be able to add arbitrary options to the form. The script should then just iterate through all these parameters.
  • Sri Kosuri 11:33, 20 June 2006 (EDT):Currently, not all the user fields in the database are being filled in. This can lead to problems. For example, if you go to the statistics and compare to the User List, there is a large discrepency. One way to alleviate this is to use the established mediawiki bot interface (which makes automatic edits by acting as a user) rather than direct manipulation of the database. Jim Hu from Texas A&M has been exploring this, and something we should look into.

Archived discussion

Demo at

To do:

  • Reject and Approve boxes should be radio buttons - these are mutually exclusive actions. Approve should be selected by default. --Ilya 14:04, 26 April 2006 (EDT)
    • George 14:21, 26 April 2006 (EDT): Agreed.
    • George 01:12, 28 April 2006 (EDT): Done.
  • E-mail dropdown box should be logically connected to Reject and Approve actions (we don't want to send a reject email to someone we gave account to and vice versa), or eliminated altogether - a simple button to edit email text should be enough. --Ilya 14:04, 26 April 2006 (EDT)
    • George 14:21, 26 April 2006 (EDT): Sri has mentioned having an option that allows you to edit an email as well as not to send one. I'll throw in some javascript to automatically select the template based on the decision but other options, like selecting a different template altogether, should still be available.
    • George 01:12, 28 April 2006 (EDT): Done.
  • Austin 10:31, 26 April 2006 (EDT): Who has permission to access the user management pages?
    • George 15:15, 26 April 2006 (EDT): That's up to you. Easiest thing would be to place a password on the directory.
    • Austin 15:47, 26 April 2006 (EDT): It would be nicer to have it integrated with OWW users and into MediaWiki. So if you either hook in and write an extension like special page for mediawiki or just grab appropriate credentials from where ever mediawiki does, then it would be possible to check if the person has sysop privileges (as any sysop can create accounts anyway).
    • George 16:05, 26 April 2006 (EDT): Sounds good, I'll work on that after getting the other things fixed up.
    • Sri Kosuri 22:47, 26 April 2006 (EDT):I don't think this is a good idea for a couple of reasons. First, I have been encouraging George to keep it as independent from altering the wiki code as possible. The less hooks there are to the mediawiki code, the less we have to maintain. Second, for now at least, I'm not sure it makes sense to give all sysops the ability to add other users... especially if it becomes really easy in general to add users. I like the ability to control a new user's first experience by telling them to go the getting started site (et cetera).
    • George 06:23, 27 April 2006 (EDT): This option could be implemented as part of the UMS without affecting wiki but it's up to you if you want to have it.
    • Austin 10:05, 27 April 2006 (EDT): I don't know what you mean Sri. Sysops already have the power to add other users. Giving them access to this doesn't really do much. But if you want, you can also limit it to bureaucrats or make a new group. In any case, I think it makes much more sense to use all of the builtin permission/user code that's already in MediaWiki rather than invent one. The UMS can't be independent of MediaWiki as it is (I'm assuming) directly changing the mediawiki user tables. It's actually less likely to require maintanence if you use the published MediaWiki interfaces (such as the public hooks and extensions) then if you go in behind it and edit the database directly.
    • George 20:46, 27 April 2006 (EDT): It is independent as in it doesn't modify wiki files/database. The user info is entered directly into wiki's database of course. I don't think that qualifies. Overall, I think it'd be a good way to authenticate users since Sysops already have the same privileges anyway.
  • Austin 10:31, 26 April 2006 (EDT): The email sent on approve/reject contains a mime part of text/plain which contains HTML which really is annoying to read in my mail client. Either eliminate the text part so that my client forces HTML or much more preferred, eliminate the HTML part and ensure that the email only contains text.
    • George 15:15, 26 April 2006 (EDT): Forcing HTML is probably not a good idea, I'll strip the text of all formatting for the plain text version. Thanks for bringing this up.
    • George 01:12, 28 April 2006 (EDT): Done.
  • Austin 21:46, 26 April 2006 (EDT): Not sure if /um.php is supposed to go anywhere (when clicking on logo)
    • George 06:17, 27 April 2006 (EDT): The link should point to "um.php" not "/um.php". I'll change that with the next update.
    • George 01:12, 28 April 2006 (EDT): Done.
  • Austin 21:46, 26 April 2006 (EDT): It would probably make most sense to have the default screen show all user's full info by default (or have a button to show all/hide all).
    • Sri Kosuri 22:47, 26 April 2006 (EDT): I don't agree. I like it the way it is.
    • George 06:17, 27 April 2006 (EDT): I don't think showing full profiles by default is very convenient if you have a lot of requests. I'll add show/hide all link but keep them hidden by default. This kind of speculation is better solved once the system has actually been used I think. We'll see what will be easier.
    • Austin 09:59, 27 April 2006 (EDT): I don't see how you can approve or reject without seeing the full profile so it seems that showing the limited information is useless, regardless of how many requests you have.
    • George 01:14, 28 April 2006 (EDT): Done. I added the show/hide all link. It's hidden by default but let me know if you want to flip that.
  • Sri Kosuri 22:47, 26 April 2006 (EDT): George, can we make it such that the admin email also gets a copy of the application. This is in case this software ever goes down, we have a backup to accounts that were possibly not added.
    • George 06:17, 27 April 2006 (EDT): Yep. The request that is stored in the UMS database is currently not deleted after being approved or rejected, its status is just changed such that it doesn't show up in the pending requests anymore. That gives another backup source if something happens to the wiki db. But e-mailing the details is also good in case it never makes it to the database.
    • George 01:12, 28 April 2006 (EDT): Done.