Bug: password reset assumes root user ID of 0

[mtbcarroll]

Looking at password in db.py it appears to assume that root's user ID is 0. Shouldn't it be checking the Roles object? Or, at least, if the server isn't available, joining with the experimenter table to find out which is actually named root?

[jamoore]

Then let's implement or close. (There may need to be a general conversation about which is the most definitive: ID or name. On Unix, it would be ID)

[mtbcarroll]

A lot of code avoids assuming 0: for instance, the admin service prevents changing root's name from root (which wouldn't much matter if we could still assume id 0, Unix should still work with root renamed), views.py bothers with expressions like conn.getAdminService().getSecurityRoles().rootId, and on startup the server regards the name as the authoritative datum in doing a,

select id from experimenter where omeName = 'root'

which make me wonder what assumptions have already been pervading the code.

[jamoore]

Looking at password in db.py it appears to assume that root's user ID is 0. Shouldn't it be checking the Roles object? Or, at least, if the server isn't available, joining with the experimenter table to find out which is actually named root?

Making calls directly to PSQL has been something we've largely avoided from the CLI, so I don't think that's in scope to change here. If you think we should add a proper call in before doing this, we can look at doing so, but in general db assumes that no server is present, i.e. you've lost your password etc. so I'd tend to vote no on that. That then only leaves whether or not root or 0 should be definitive, which is a pretty large undertaking. (I'm inclined to vote for 0 so that someone could make there root name more i18n friendly.)

All that taken into account, I'm pushing. I'm open to suggestions/discussion, but I think mostly this should be a "rationalize Roles usage" RFE.