Google Apps: Show errors from backend if present

[klimeryk]

Best served with D2121-code which adds proper error handling when fetching Gapps users. This PR refactors a bit the Gapps code to show those errors.
Additionally, I've found and fixed a bug: the Add Google Apps users button on the site-wide Google Apps page added the users to a random domain, it was impossible to select which one. Now, there's a button for each domain.

Before

Selected domain:

Site-wide:

Site-wide with an error for one of the domains:

After

Selected domain:

Site-wide:

Site-wide with an error for one of the domains:

/cc @aidvu @umurkontaci

Test live: https://calypso.live/?branch=fix/gapps-get-users

[umurkontaci]

Code 👍

I'm not a big fan of using a notice in place of a card. Do we have another design pattern for empty lists like this? (cc: @breezyskies )

Now that we have a better idea why the user ends up with no user accounts, do we have any plans for letting the users to know and help them fix it if possible? Currently it looks like something went wrong but they have no idea why and how to fix it. Also, if we charge them when the provisioning fails, and the only actionable button here is Add Google Apps Users, which is going to be another charge if they go through.

Though I'm concerned on the fact about UX, this is much better than it was before as it was making the whole site unusable, so none of these are blockers and OK to address them later in another PR.

[klimeryk]

I'm not a big fan of using a notice in place of a card. Do we have another design pattern for empty lists like this?

I'm not a fan too, but this is a special case - no users means something went wrong, this shouldn't happen. Either we are still setting up the Gapps account or there was an error during provisioning and they need to contact support. There's also a possibility that a different error is returned by the backend.

Inspired by your comment, I had a chat about this with @Lochlaer and decided to change the behaviour of the notice based on the subscription's age:

• If it's been <24 hours since the user signed up for Gapps, show a friendlier message, reassuring that Gapps is being set up and asking them to be patient.
• If it's been >24 hours, be less confident and ask them to contact support 😁

[breezyskies]

I'm not a big fan of using a notice in place of a card. Do we have another design pattern for empty lists like this?

There isn't another design pattern that I know of for a list view like this. We usually use a whole page empty state, but that doesn't really apply here.

If it's been <24 hours since the user signed up for Gapps, show a friendlier message, reassuring that Gapps is being set up and asking them to be patient.
If it's been >24 hours, be less confident and ask them to contact support 😁

This makes sense to me. +1 for giving them a link to support (if there's an issue, let's give them an actionable way to try and fix it). I would also tone down the colors on the friendlier version, maybe using the default notice style.

[klimeryk]

Thanks for the feedback, Brie! 🙇 The changes to make this happen shouldn't be big (and the notice as is now could lead to some confusion and unnecessary HE involvment), so I'll try to implement them as part of this PR.

[klimeryk]

I've added a friendlier notice when the subscription is younger than 24 hours:

And a link to contact support for the less friendly notice after that:

[breezyskies]

Design changes look good, but I'm not sure about the "please be patient" copy. cc: @ranh

[ranh]

We have a similar notice for new domains, let's reuse that here:

We are setting up mail@example.com for you. It should start working immediately, but may take up to (72 hours).

Just change 72 hours to whatever is relevant here.

[klimeryk]

Thanks for the feedback and suggestions, @breezyskies and @ranh! 🙇
The "friendly" notice now looks like:

[umurkontaci]

LGTM 👍

Just a future idea to step up our game, when something is wrong, instead of telling the user to contact support, we might want to auto-create tickets to solve the problem before ourselves, either with a job or upon producing this error. We can then tell the user that something is wrong and that we are working on it.