Username was designed as a convenient moniker for users to use in place of their system ID for login. The super user account most likely never got a username because it had a convenient/special system ID (“admin”). I don’t think there is any harm to this account having a username other than the special case of our infrastructure locking down the account to prevent abuse (e.g., changing the password) of public systems.
What we missed in adding the username was ensuring this was done by default in the SDK (rather than relying on the liquibase change). If the SDK generates an admin user with a username, the problem will resolve.
I agree with Burke, it sounds confusing to me to create the data without username, and then fix it via liquibase.
If we change the data creation, it would cover any new instance of OpenMRS. My question is: is there any need to fix existing OpenMRS instances? (note that all our test services are recreated every couple of days, so it’s just a new server).
@permissionerror I do plan on doing this tonight, but if you are free you can do it before that.
So we need to go to the sql in all refapp and platform environments , and edit the SQL to add a username to the ‘admin’ user. We’ll roll it out using ansible as usual.
We’ll have to destroy and recreate all environments after that.
@cintiadr , now that that PR is merged , is there any more work to be done ,to have the qa-server up again ,apart from re-running the bamboo deployment plan ??
Ansible changes is not deployed automatically. I will roll it out now.
My question is: now that we changed the SDK to generate the correct data and fixed our servers, shouldn’t we delete the liquibase changes? As this is a problem with the original data.
So if I understand what @burke is suggesting, it’s the same thing I am suggesting.
That we don’t do the liquibase change, unless there’s any reason to say that this needs to be done for existing OpenMRS instances. I still don’t know if that’s the case, it seems a little bit odd.
@dkayiwa, @mozzy, the fix on the SDK looks good to me. I’ve been testing with fresh instances of the platform having the reverted change set, using the SDK and irrespective of the platform version, the admin user name is assigned to the systemID of admin. Looks like we are fine to revert the liquibase change set.
Thanks for this @dkayiwa, I’m not sure if I clearly understood the motivation behind reverting the change set (keeping the original data consistent since there is a fix in the SDK). This will definitely affect those not using the SDK. So this now gets a little bit not clear to me whether to revert the liquibase change set or not.