If you too have been annoyed too often by OpenACS presentations that were interrupted with "Now let's login as Peter to see that this item appears on his list ... what was his email and password again? ... no, that one was wrong ... ok, logged in - where was that page that I wanted to show you? ..." and so on, then check out my demo-login package at: http://openacs.org/new-file-storage/one-file.tcl?file_id=307

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.)

I haven't seen that yet - thanks for the hint. (I knew I had to check it out someday but then i forgot to)

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.)

Developer Support doesn't work because it is packaged as an add-on. It requires extensive support from the request processor to work at all so there's no real utility having the interface in a seperate package.

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.

It seems a bit drastic to say that the only way we can restrict access to 'powerful' functions is by completely removing the code.  The user switching feature is disabled by default, and restricted by the permission system to admins. Besides, similar functionality is present within the acs-admin pages ('become this user'), restricted to admins. What's the difference?

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.