The XUL client would remove the workstation from the local config, log the user in, then present the user with the workstation registration interface. The browser client does not require a workstation, so after we clean up the bogus WS, we'll have more options to consider.
The simplest work flow for now might be:
* Login fails with WORKSTATION_NOT_FOUND
* Delete the bogus WS from "eg.workstation.default" and "eg.workstation.all" via Hatch API
* Log the user in without a workstation
* Show a dialog to the user explaining that the workstation does not exist then offer two options: 1) go to the workstation admin page (admin/workstation/index) or 2) continue without a workstation.
Related to this, I've been considering whether we should add a toggle for "this computer requires a registered workstation", similar to the existing "This workstation uses a remote print / storage service" toggle. That would of course change the proposed work flow.
The XUL client would remove the workstation from the local config, log the user in, then present the user with the workstation registration interface. The browser client does not require a workstation, so after we clean up the bogus WS, we'll have more options to consider.
The simplest work flow for now might be:
* Login fails with WORKSTATION_ NOT_FOUND .default" and "eg.workstation .all" via Hatch API workstation/ index) or 2) continue without a workstation.
* Delete the bogus WS from "eg.workstation
* Log the user in without a workstation
* Show a dialog to the user explaining that the workstation does not exist then offer two options: 1) go to the workstation admin page (admin/
Related to this, I've been considering whether we should add a toggle for "this computer requires a registered workstation", similar to the existing "This workstation uses a remote print / storage service" toggle. That would of course change the proposed work flow.