Comment 4 for bug 1467663

Taking required workstations into consideration, I have some additional thoughts on this.

For starters, we probably should refactor the workstation admin page to function as a standalone dialog so it can be accessed from the login page and from the admin page. This way we're not duplicating code.

For the work flow, I see 3 scenarios:

Scenario 1: No WS is registered (new users).

1. Hide the workstation selector by default, since it's empty.
2. Allow the user to log in w/o workstation.
3. Display the WS admin dialog.
4. Message within the dialog explains that a WS is required.
5. After registration, log out, reload the login page.

This is basically the XUL client work flow for new logins.

Scenario 2: a single invalid WS is registered

1. Remove the invalid workstation from local storage
2. Log the user in w/ the already provided credentials (w/o workstation)
3. Display the WS admin dialog.
4. Display a message to the user saying the WS was invalid and the user needs to register a new WS
5. After registration, log out, reload the login page.

Scenario 3: multiple WS's registered.

1. Remove the invalid workstation from local storage
2. Leave the WS selector visible, so the user can select a different WS.
3. Display a message to the user explaining the WS was invalid, they can either log in w/ a different WS or register a new WS. The message contains a link/button to launch to WS admin dialog.
4. If clicked, Display the WS admin dialog.
5. After registration, log out, reload the login page.

To prevent users from navigating away from the login page (or WS dialog) when no workstation is present, we add a check to the auth service code which redirects to the login page when egAuth.user().wsid() is null. (There's already an if{} block in the code for this).