Forum OpenACS Q&A: demo login package
It features a list of demo user accounts with a "become this user" button next to each, lists the user's group memberships and optionally some demo account description. The accounts are selectable from existing user accounts by an admin.
It also contains a little template intended to be included at the footer of default-master.adp that alway displays the currently logged in username and a link to the demo-login instance.
If there's interest then I can polish it up a bit, add some documentation etc.
(It's OpenACS 4, currently postgresql only btw.)
Although the user-switch in developer-support is quite useful it does not provide some features that I needed and added to the demo-login package, so it is not a complete duplication of effort: first, demo-login allows for unattended demonstration installations where for some reasons you do not want to allow the tester to become site-wide admin or some other privileged user. Second - the ability to add some explaining text to each account, so that the testing user knows what the account is supposed to demonstrate. This is useful for demonstrations that include different users with very specific different roles, e.g. in a particular customization of a workflow.
Btw, I found a problem with the developer-support user switch: it replaces the two procs ad_get_user_id and ad_verify_and_get_user_id with it's own implementation, but not the behaviour of [ad_conn user_id], which is used quite often in the toolkit (and seems to be the preferred way since the both procs above are -deprecated).
A possible way to fix this would be to overload ad_conn in acs-developer-support-procs.tcl as well. Any better suggestions? (I've entered a bug in the sdm for that.)
I was the original author of the user-switching feature, because I got fed up with logging in time and again while developing workflow. Without looking, I doubt that anybody have really spent much effort trying to keep it up-to-date, including me.
At the time it was developed, [ad_conn user_id] wasn't used. So indeed, one approach would be to overload that one, too. Or we could find a whole new way of doing things, by hacking into the procs parsing the cookies, or see if there's some other single spot that we can hack the user-identification chain for our purposes.
Hm. Rambling here. Haven't actually looked at the code.
The disadvantage is that no one is aware of the user switching functionality (it overides core procs, breaking the doumentaed behaviour...) so when things change, it breaks.
The reason I mention it is because your package is so useful, adds no overhead, and is unlikely to have many implementations, that I think it would be a shame to have a second seperate package to implement what really is core ACS functionality.
I don't mean to labour the point, but the lack of integration within ACS is my pet peeve. The extensive duplication of 50% solutions makes it extremely difficult to understand and build upon.