Item9796: Improve docs for AdminUser

• AdminUser should have a note stating something to the effect: "Do not add AdminUser to your .htpasswd file or other authentication system. You should only access the AdminUser through the sudo login interface. Logging in with the WikiName through the normal authentication process will not acquire admin rights. Become AdminUser by logging in as the admin login name, defined in Configure (by default this is "admin").

• AdminUser should not be listed as eligible for "remove user" in the Group API for the AdminGroup. The AdminUser is internally generated and cannot be removed. Deferred

• When the Group UI fails to add/remove a user from a group, it needs to log/report why the failure occurred. Deferred

• Since AdminUser is shipped by default, consider shipping a "AdminUserLeftBar" I've found it very helpful to have a warning that I've sudo'd to the admin user

%TABLE{databg="red"}%
| ADMIN USER |

<!--
Customise this topic; samples and ideas available at %SYSTEMWEB%.WebLeftBarCookbook.
--> *My links:*
   * [[Main.AdminUser][My home page]]
   * [[%SCRIPTURL{search}%/%BASEWEB%/?search=AdminUser;order=modified;limit=50;reverse=on][My %BASEWEB% activities]]
   * [[%LOGOUTURL%][Logout]]
<a class="foswikiSmallish" href="%SCRIPTURLPATH{"edit"}%/%WEB%/%TOPIC%?t=%GMTIME{"$epoch"}%">edit</a>

-- GeorgeClark - 06 Oct 2010

Updated documentation in AdminUser topic, and added the left bar. Waiting for feedback from KennethLavrsen if okay to add to release MANIFEST. And ArthurClemens - anything you can do with the javascript?

Note the reason I added the Left Bar is I found ongoing that I was constantly forgetting that I had issued the sudo login, and next thing I knew, I was editing and accessing things - leaving changes attributed to the somewhat anonymous AdminUser and accessing things that should have been denied. A default left bar for the default AdminUser is a handy reminder that the current login has admin rights.

-- GeorgeClark - 19 Mar 2011

In Item10510 I am working on the logic of the group actions. UPDATE: GROUPINFO lacks the possibility to exclude members; new Task: Item10511.

Regarding the sidebar, I think we need something skin independent, for instance a bar at the top like http://stackoverflow.com

The current change looks quite bad:

-- ArthurClemens - 19 Mar 2011

Well - It's something that is only seen by "the" Admin user, either logged in or with sudo. It's the sample left bar that everyone gets - with the addition of a fixed red ADMIN flag, and a logout link so one doesn't have to navigate back to the AdminUser topic to find the logout.

Figuring there was only a very small subset of users seeing it, and it was minimal tailoring of the default WebLefBarExample topic ... Beauty in the eye of the beholder I guess, it addresses something that continually "bit" me.

We can ship it as a sample, as is or beautified, or toss it I suppose, not particularly consequential. I didn't add it to the MANIFEST file, so it's not going anywhere anyway.

-- GeorgeClark - 19 Mar 2011

Here is the look with the default skin and the latest changes

-- GeorgeClark - 20 Mar 2011

OK with me. AdminUser is not what I consider a normally tailored topic. Normal users should never bump into it

-- KennethLavrsen - 20 Mar 2011

The documentation for AdminUser has been updated and the AdminUserLeftBar added to the MANIFEST. The other issues - filtering AdminUser from the group API for only the AdminGroup, and better error reporting, are deeper and should be handled on separate tasks.

• The Group UI uses %GROUPINFO% to list the users for remove selection. However the macro has no filtering capabilities. See Item10511
• The Group UI and functions in the Mappers don't have any obvious error handling capability. Multiple operations can be performed on a single request with partial success. This probably needs a feature proposal to discuss implementation.

Commenting is disabled while not logged in