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
>