This also means, that we are not able to change roles of a user.
P2 -> P1

reassigning to support

The issue with the initially blank Administer usres screen has been
filed with an engineer for investigation. The users are available if a
search is conducted on this screen for a particular keyword or user
name, which should allow you to modify roles.

I am not sure I understand your second point, could you please
describe further?

Thank you

I logged in as mh, worked for a little while, left the application for
some hours idle, then clicked on "my Issues" and saw the bugs of
someone else. clicked on "edit profile" and saw the profile of
somebody else.

I'm still looking for a workaround to assign cmc@openoffice.org the 
project lead role in the sw project.

ok, the work around is:

- make the project owner role requestable
- send mail to person that he/she rquest role
- approve role
- reset requestable role again

not nice but works.

Thank you for the explanation, and I am glad you were able to
workaround the problem of adding a user to a project. An engineer is
looking into the larger issue and we will hopefully have a solution
soon.
I am still looking to reproduce the second issue you raise of being
presented with another user's issues and profile without changing your
login information.

I have not yet been able to reproduce the error of seeing another
user's information after being idle on the site for a period of time.
I am always requested to log in again.

The Administer Users issue is with an engineer .

I'm also not yet been able to reproduce the error of seeing another
user's information after being idle on the site for a period of time
anymore. 

Interresting. I'll try a bit more and see if anything comes up.

Continuing to investigate the user handling issue next week.

fwiw, I've had some people register, login, and then find that SC has
interpreted their logins as somebody else's.... quite disturbing.
cheers
louis

Louis - if you can see a common thread for that behavior please let me
know.

Further work will be done this week on the staging server pertaining
to the main administer users issue. 

I have another guy with problems here. He can't submit issues. His
login is pde (Peter Eckersley). I can find him as a registered user,
when I use the user administration. But I can't find him as a user in
IssueZilla, which is certainly the reason why he can't submit bugs.
Just wanted to mention this, in case it's related to this bug.

That is odd. Do you know when this user was created (recently/long
ago)? 

my guess and it is only a guess is that it may be necessary to 
run a script to update all the user databases. We can do this 
perhaps when we migrate to Solaris.
louis

Changing whiteboard to reflect issue council marker.

It is possible the user was "lost" because of optimizations made to
the issue tracker rebuild process to deal with the large number of
users on the site. Triggering a full rebuild may resolve this issue
but would impact site performace while it runs. 
Durring the migration all databases should be updated.

The launch of the staging server has been delayed by two days and is
currently planned for Tuesday of next week. We appologize for the
delay.

Myself and Louis experienced blips in identity recently. Issue pcn9876
has been entered for investigtion of this phenomenon.

There are no further developments to report on the main user handling
issue.

The staging server has been built and populated with data. The domain
change work (ref to openoffice.org -> solstage3) is underway now. The
process of copying data and making the changes has taken longer than
originally expected, and the server should be available tomorrow
rather than today as planned.

Periodic sandbox restarts have been initiated as an interrim solution
for the problem with user identity confusion.
A permanent fix is being investigated by an engineer.

We have not experienced this issue so far on the staging server. We
will continue to watch for this behavior.

Investigation on the production server has uncovered evidence that the
problem has to do with the number of results being returned from the
database. We continue to look into this and the relationship to the
version on the staging server.
.

Actually mistaken in my last statement. The problem with retrieving
large amounts of data from the database lies a few layers below any SC
code. The difference in platform is probably what is being reflected.

The user administration issue has been addressed by resetting
arguments to the JVM. A listing of users is now displayed for
administration.

The user confusion issue is still being investigated.

Debugging scripts have been installed on the server to help diagnose
the user confusion issue. Developers will be looking into what they
have gathered on Monday.

Nothing significant has yet been found in the files generated by the
debugging scripts. We are continuing to look into this.

No incidence of the ghosting behavior has been caught by the script to
this point. As soon as an incident is captured debugging will proceed.

This behavior has still not been captured.

The watched error never appears. The user confusion behavior has still
not been captured.

We have not captured this behavior in a week without sandbox restarts,
and suspect that it was resolved by the change made to the JVM
allowing administration of users.
I am closing the issue at this time. If the behavior resurfaces it can
be reopened.

removing from top5 and closing