<div dir="ltr"><div>Thanks, Terran.  Comments inline below.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 11, 2022 at 10:47 AM Terran McCanna <<a href="mailto:tmccanna@georgialibraries.org">tmccanna@georgialibraries.org</a>> wrote:</div><div class="gmail_attr"><snip></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>Questions: <br> - How would it handle the workstation name? Would staff need to set it up at first use? (Note that it would be useful for it to have a workstation name that indicated that the offline app was used for each transaction so we could identify offline transactions in reports/logs.)<br></div></div></blockquote><div><br></div><div>The workstation can either be entered/registered in the standalone application directly or, if Hatch is running, it could pull the workstation info from Hatch or directly from the disk.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> - Would the staff client still be able to tell if there were pending offline transactions to upload? (Note that it would be nice to see this alert once logged into the staff client as well as on the login page.)<br></div></div></blockquote><div><br></div><div>The standalone app will have to communicate to the EG server to pull down some data (as Jason mentioned in his email).  That opens the door to expanding communication and streamlining.  For example, once the network is restored, the standalone app could post the pending transactions directly to the EG server where they are kept in a staging area awaiting processing.  Or it could post a simple "you have X pending transactions" to the server in a place the browser client knows to check at login time.</div><div><br></div><div>Alternatively, if Hatch is involved, it could be informed of the pending transactions and communicate that to the browser client.  </div><div><br></div><div>There are probably other options.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> - Would this resolve the problem of not being able to download large patron block lists? (PINES hasn't been able to download block lists at all since moving to the web client.)</div></div></blockquote><div><br></div><div>Yes, I would expect this to be resolved.</div><div><br></div><div>I imagine the standalone app could run as a background / startup service that pulls data (new org units, noncat types, blocked patrons, etc.) at regular intervals without any staff intervention.  I also like the idea of a "force refresh" option built into the standalone app.</div><div><br></div><div>-b</div></div></div>