Apparent error in 2.1.6 upgrade script about indexhibit

[Indexhibit]

Oh my, some of the things that have not been noticed for ages - I was not aware of this error. I'll fix it shortly. Years ago I noticed many people were disabling their admin rights accidentally (another bug) and so I added that to make/keep the primary user an admin (kind of a super admin). I'm unsure if I should remove it completely (instead of fixing it). People are going 15 years now without upgrading (a bit frustrating to be honest but if it works that's great, I guess).

[universalhandle]

My two cents: addressing the accidental self-removal of admin rights in an upgrade step seems misplaced unless it was a widespread issue introduced in a specific release (e.g., a different database upgrade caused it, or it was impossible to submit the user form without de-adminning). I'd remove it completely, myself.

For lockouts caused by user error, a twist on the password reset utility seems more appropriate. Accidentally disabling de-escalating your privileges is basically a variation of the same problem: the user goofed their login somehow, and now we have to resort to extreme measures to regain access.

Even in the examples I presented, though, the fix seems somehow simultaneously too broad and too narrow. It's too broad in that it assumes that the user who installed Indexhibit is and will always be a trusted user. It's too narrow in that if the de-adminning problem affected any user besides 1, it doesn't restore their access.

In some respects, including this script in an upgrade step represents a low-grade security risk. Suppose I intentionally took away user 1's admin privileges, then upgraded the instance. This upgrade step would silently re-escalate their privileges.