Bamboo Build Failure Due to Platform Upgrade

Tags: #<Tag:0x00007f3031acd1c8>

am seeing a talk post here , why they had to do it that way

here is the commit that has caused problems , is there are way we can add another pre-condition , so that ,that change set doesnt run on our servers ?? cc @dkayiwa

Look, I don’t want to leave open for others to change the admin’s username in our servers.

I could just change the sql to have ‘admin’ as the username, BUT the SQL I have was generated from the SDK. I wonder if it should have been fixed there instead of do a migration. I’m not even sure if this needs to be a data migration or if the intent was only fix the demo server.


if you do that , the above change set wont run , so we wont have any issues ,as the pre conditon looks for any existing user named “admin”

Hello, The fix was provided by me and the reason was we needed the admin user to have a username. For some reason it was never present and was using the system-id.

But the question is: was the problem only relevant on the demo server? Was there any benefit to updating that in all OpenMRS instances when upgrading it? Wouldn’t it be better to just change the initial data instead?

Our problem was not regarding the demo server. I had given that as a reference in the talk. In our implementation, we were using the session API to fetch the username of the logged-in user and use it further.

We figured out it was not working because of admin user not having a username and we raised a fix. Was it not given a username intentionally?

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

I have just released a new version 3.13.3 of the SDK which generates an admin user with a username.


Thanks @dkayiwa

@dkayiwa do you want me to change our test environments to have that fix?

1 Like

Yes that would be great @cintiadr

1 Like

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

1 Like

@cintiadr created a ticket here

see PR

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

1 Like

I think its still relevant for implementers who may run OpenMRS the Enteprise way , that is people who dont use the SDK or the standalone .

Well done @cintiadr. Our qa-server is now up again :grinning: