Resetting user credentials

[costateixeira]

Sometimes I get "invalid credentials" when logging in, and I have no idea how to reset those (for the admin@eu, admin@be).

Is there a way to reset other users' credentials? I couldn't find it in the docs

[costas80]

Sure, if you login as the Community administrator (the admin@fhir.eu account) you can reset both your own password as well as that of other users in your community:

• For your own account see here.
• For other administrators' accounts see here.
• For other users' accounts see here.

In all cases you'll be setting a one-time password that will need to be changed upon login. Let me know if you're still having issues after this.

[costateixeira]

@costas80 in some cases I have been unable to log in as admin@fhir.eu or admin@fhir.be, and I was trying to see how could I change the logins of those users, which I did not find. Is there a way to do that?

[costas80]

@costateixeira, that is odd indeed. You can change their passwords by logging in as the overall Test Bed admin and changing passwords as I listed in the documentation links above.

The Test Bed admin's account has not been changed for the PoC and is still marked as a one-time password to replace at first login. To do so login providing test@test.com and test as the credentials. Upon doing so you will be immediately prompted to change your password and set the one you want. Once connected as Test Bed admin you can manage all users be it community administrators (the admin@fhir.eu account), as well as organisation users (the admin@fhir.be account).

Remember that in all cases you will be setting one-time passwords when replacing users' passwords (you can set any value for these) that the users will need to replace on first login.

[costateixeira]

Thanks, I tried that but when logging in as @.***, I don't know where to find the other users. The list of communities is empty, so I cannot manage its administrators. Any idea of what I might be missing?

On Wed, Dec 13, 2023 at 9:22 AM Costas Simatos @.***> wrote:

@costateixeira https://github.com/costateixeira, that is odd indeed. You can change their passwords by logging in as the overall Test Bed admin and changing passwords as I listed in the documentation links above.

The Test Bed admin's account has not been changed for the PoC and is still marked as a one-time password to replace at first login. To do so login providing @. and test as the credentials. Upon doing so you will be immediately prompted to change your password and set the one you want. Once connected as Test Bed admin you can manage all users be it community administrators (the @. account), as well as organisation users (the @.*** account).

Remember that in all cases you will be setting one-time passwords when replacing users' passwords (you can set any value for these) that the users will need to replace on first login.

— Reply to this email directly, view it on GitHub https://github.com/medigree/fhir-itb/issues/4#issuecomment-1853459422, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUH3VTPRKSTJ52TH6I3YJFQTRAVCNFSM6AAAAABARRLP4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJTGQ2TSNBSGI . You are receiving this because you were mentioned.Message ID: @.***>

[costas80]

Ah I understand what the problem is! I had mentioned this when I sent the PoC's resources but didn't highlight it enough.

When the Test Bed starts up it reads the data archive from the configured folder and then removes it. The reason for this is because a "sandbox instance's" population is normally meant to happen only once on the very first startup. This is done to avoid the archive getting continuously picked up and reprocessed at every restart.

Checking the resources in the repo and comparing to the docker-compose.yml, the data archive should be present at ./config/data/export.zip, however this is missing. The result is that the Test Bed currently starts up, doesn't find an export archive to process and proceeds with an empty instance (which is what you describe upon login and also why you cannot authenticate using the other accounts which have never been created).

To address this you need, before starting up the Test Bed for the first time, to copy ./export.zip to ./config/data/export.zip. After the first startup that processes the archive, you would only need to reprocess it if you completely delete the Test Bed's data via docker compose down -v.

If this design causes any issues with the setup via Git repository (e.g. displaying a resource deletion to commit after first startup), we could revisit this to see how to adapt the startup so that it doesn't reprocess the archive but also not delete it (e.g. record a hash of all processed archives and only process different ones).

[costas80]

we could revisit this to see how to adapt the startup

This seems to be quite simple to address and will make management via Git repository of such a configuration more clear. We will do the update asap and publish on our nightly channel. I'll let you know here @costateixeira when this is ready to pull.

[costateixeira]

thanks. I saw the remarks about deleting the export file, but i didn't see that this would include communities and users. Restoring it works, thank you again

On Wed, Dec 13, 2023 at 9:54 AM Costas Simatos @.***> wrote:

Ah I understand what the problem is! I had mentioned this when I sent the PoC's resources but didn't highlight it enough.

When the Test Bed starts up it reads the data archive from the configured folder and then removes it. The reason for this is because a "sandbox instance's" population is normally meant to happen only once on the very first startup. This is done to avoid the archive getting continuously picked up and reprocessed at every restart.

Checking the resources in the repo and comparing to the docker-compose.yml, the data archive should be present at ./config/data/export.zip, however this is missing. The result is that the Test Bed currently starts up, doesn't find an export archive to process and proceeds with an empty instance (which is what you describe upon login and also why you cannot authenticate using the other accounts which have never been created).

To address this you need, before starting up the Test Bed for the first time, to copy ./export.zip to ./config/data/export.zip. After the first startup that processes the archive, you would only need to reprocess it if you completely delete the Test Bed's data via docker compose down -v.

If this design causes any issues with the setup via Git repository (e.g. displaying a resource deletion to commit after first startup), we could revisit this to see how to adapt the startup so that it doesn't reprocess the archive but also not delete it (e.g. record a hash of all processed archives and only process different ones).

— Reply to this email directly, view it on GitHub https://github.com/medigree/fhir-itb/issues/4#issuecomment-1853503870, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUHO4UKAK4WEU5TXVTTYJFUKXAVCNFSM6AAAAABARRLP4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJTGUYDGOBXGA . You are receiving this because you were mentioned.Message ID: @.***>

[costas80]

@costateixeira, the discussed update is now published in the nightly build channel. In brief, processed archives are no longer removed but rather their SHA256 hashes are recorded to make sure they are not reprocessed. If you restart the Test Bed and it finds an archive that has already been imported you will see the following line in the gitb-ui logs:

...
2023-12-13 11:49:33 13/12/2023 09:49:33 INFO  ImportCompleteManager - Skipping data archive [data.zip] as it has already been processed on [13-12-2023 09:47:41].
...

Like this we'll no longer have such misunderstandings and also we will not have removed files in the Git pending updates. Thanks for proposing (well, at least inspiring) this nice update :)