Comment 2 for bug 1467663

On Fri, Jul 3, 2015 at 3:57 PM, Bill Erickson <email address hidden> wrote:

> 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.
>
>
That (and part (2) above) would get a big -1 from me. Trying to use the
web staff client without a workstation registered is only going to get
worse than it is today -- spurious patron-only template includes, bad
default location assumptions, crossing the streams with user settings,
etc. I think requiring registration is the only way forward.

However, we'll need to make local storage (both hatch and in-browser) more
robust, because if you turn on hatch today on a workstation that has been
in use without it, you "lose" all your local settings, because in-browser
settings get ignored if hatch is there and you use the generic get/set
methods.

--miker

> --
> You received this bug notification because you are a member of Evergreen
> Bug Wranglers, which is subscribed to Evergreen.
> https://bugs.launchpad.net/bugs/1467663
>
> Title:
> Cannot login to web staff client if work station does not exist in
> database
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> Evergreen Version: 2.7+
> OpenSRF version: 2.4 (but doesn't apply)
> Postgres version: Doesn't matter
>
> If you have registered a workstation with the web staff client that
> subsequently disappears from the database, you cannot login via the
> web staff client until after you have cleared the workstation entries
> from local storage in the browser. This is not likely to come up in
> production environments, but could easily arise in training or demo
> situations where the database is refreshed periodically.
>
> To reproduce this bug,
>
> Login with the web staff client.
> Register a new workstation from the Administration menu.
> Logout and log back in to see that the registration is working.
> Logout of the web staff client.
> In PgAdmin or some other database tool, delete the entry from
> actor.workstation for the workstation that you registered above.
> When you next try to login with the web staff client, the login will
> fail.
>
> The osrfsys.log will have entries like the following for each failed
> login attempt:
> open-ils.auth 2015-06-22 15:40:02
> [INFO:30482:oils_event.c:46:1435002001306031]
> Creating new event: WORKSTATION_NOT_FOUND
>
> If you clear the workstation information from your browser's local
> storage for the domain where you are using the web staff client, you
> will be able to login again, but you will need to register your
> workstation again.
>
> The above also assumes that you have only registered 1 workstation. If
> you've registered multiple workstations, you can still login with any
> that exist in the database.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1467663/+subscriptions
>