EG/Hatch options for improved browser data-clearing resiliency
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Evergreen |
Confirmed
|
Wishlist
|
Unassigned | ||
Bug Description
Evergreen 3.3
With the advent of workstation settings, most of the web client data that needs to persist (preferences, etc.) are safely stored on the server. Clearing browser data (localStorage in particular) has no impact on the stored preferences, but it does wipe away 2 crucial settings which tell the browser a) what workstations it has registered and 2) whether to use Hatch for printing. This data has to be manually re-added if the browser's data is cleared.
To close the gap and make it so Hatch-enabled machines can gracefully recover from a full browser reset, I propose the following:
1. Make the "eg.hatch.
2. Add another workstation setting "eg.hatch.
3. At login page load time, the browser first checks localStorage for workstation data. If it finds none, it asks Hatch if it has any workstations. If yes, pull the data and continue as usual.
4. At workstation registration time, if "eg.hatch.
5. If a browser already has workstations in localStorage and enables the "eg.hatch.
| Changed in evergreen: | |
| status: | New → Confirmed |
| Changed in evergreen: | |
| milestone: | none → 3.4-beta1 |
| Jeff Godin (jgodin) wrote | #1 |
| Jeff Godin (jgodin) wrote | #2 |
| Bill Erickson (berick) wrote | #3 |
| Bill Erickson (berick) wrote | #4 |
| Kyle Huckins (khuckins) wrote | #5 |
| Changed in evergreen: | |
| assignee: | nobody → Kyle Huckins (khuckins) |
| assignee: | Kyle Huckins (khuckins) → nobody |
| Bill Erickson (berick) wrote | #6 |
Summarizing some discussion from the hackfest:
- We do not believe that there is reason to have a setting to enable/disable using Hatch to store workstation registrations. If Hatch is available, store workstation registrations there, if not, store in local settings.
- As a migration path, once this code is in place it should attempt to retrieve the list of workstation registrations from Local Storage and migrate them to Hatch, then remove them from Local Storage.
- This migration process may run multiple times in the case of multiple local instances of Local Storage (browser profiles or multiple OS users using the same Hatch storage dir), and should merge workstation registrations, not replace them. The first "default" workstation should remain default despite any subsequent local settings migrations potentially having a different default workstation.
- As part of this, change the default data directory (data.directory in the hatch.properties file) on Windows to a shared machine-wide directory (an .evergreen directory in %ProgramData% / $Env:ProgramData / C:\ProgramData being the most likely value for data.directory). This would be implemented by the Hatch Windows installer putting in place a default hatch.properties file or performing a string replace on that file. It might be an install-time prompt or command line argument to override this new behavior.
- Similar (but different) to the migration strategy for workstation registrations, when faced with an empty/new data.directory that isn't the default user.home + ".evergreen" directory, Hatch would look for that (formerly default) directory and migrate settings from there to the new directory. Unlike the migration strategy for workstation registrations above, this would only migrate the first encountered directory to the new/empty directory.