Infinite loading for the visualization of the users of an organization

[blainvillem]

Infinite loading for the visualization of the users of an organization :

A picture will explain better than words :

To temporarily solve the problem I have to create a fake user

Here is my version:

[BlackDex]

But, how are you able to access that org without any users in it?
That shouldn't be possible at all.

Also, try this with the testing tagged images and see if that fixes your issue.
There have been multiple changes and optimizations done on the organizations, and it also uses a new web-vault which has several optimizations.

And.. I just tested it with that same image, and it works just fine for me. But when creating an org, it already has a user, since that is me, because i created that org.

[blainvillem]

You have understood the opposite of the problem.

I have users in the organization, they do not appear (loading) until I create a new user.
I can for example create test@test.com and there the users appear then if I refresh the page it bug again.

[BlackDex]

Still, try the testing tagged images and see if that solves the issue.
I couldn't reproduce this using the latest image my self.

An error should be in the log files of Vaultwarden or the reverse proxy. Or check the browser F12 log of there is something useful.

[blainvillem]

Problem solved, I had not put a valid email address at this location:

I hope it will help other people

[BlackDex]

What did you put there before?
Because you should not be able to provide an invalid mail there at all.

[blainvillem]

I had put the name of the company which is composed of several words separated by spaces.

[stefan0xC]

I've tried to replicate this and I think this happens in rare cases when there is no private_key or public_key for an organization set and the billing_email is also not valid (which IIRC was both possible in olders versions). Because the client tries to set the missing keys automatically but can't because the validation fails, loading this page will throw an exception and only display the loading icon.

Adding the mail address fixes the validation issue and the missing keys can be added by the web-vault.

[BlackDex]

That happens only on old instances which recently were updated then i guess. Maybe there is a good sane way to fix this.

[blainvillem]

I didn't understand everything but if you need more information it's my pleasure.

[stefan0xC]

@blainvillem I was just theorizing how this could have happened (or I had it in the back of my mind that this was a possibility #2864 (comment)). Since you ran into the issue it's most likely that you have recently updated your vaultwarden installation from an older version, as those specific circumstances should not be possible with newer versions. If you can confirm this that would be nice but I don't think that it's really necessary.

The logs (from before the change) should have said something like this:

[2023-03-14 23:21:19.805][request][INFO] POST /api/organizations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/keys
[2023-03-14 23:21:19.805][vaultwarden::db::models::organization][ERROR] BillingEmail test is not a valid email address
[2023-03-14 23:21:19.806][response][INFO] (post_org_keys) POST /api/organizations/<org_id>/keys => 400 Bad Request

@BlackDex Not sure how many are affected by this (since I'd assume that many will have set a valid mail address even if not doing that was possible previously), but I don't think that e.g. adding the ability to skip this validation in the save() function just for this one (rare) use case is worth it. I think what you said in the PR back then still makes sense insofar that while not obvious the fix is relatively easy. Opening the web console using F12 would also have returned a rather descriptive error message and if more people are affected by this I think we could improve the error message (i.e. to explain that the email of the organization needs to be valid and can be fixed in the organization settings) or – since not all people will check the console – it could also make sense to write some troubleshooting guides for update issues (especially if they would require manual intervention).

[blainvillem]

I confirm that it appeared after a big version upgrade of at least 1 year