Re: [OPEN-ILS-GENERAL] Bookbags and record buckets: having my cake and eating it too?

[Jane Sandberg]

Thanks, Terran!  I think I found it:
https://bugs.launchpad.net/evergreen/+bug/1696157

On Fri, Aug 3, 2018 at 2:10 PM, Terran McCanna
 wrote:
> I thought there was a wishlist ticket in launchpad for something like this,
> but I'm not finding it now - but +1 from me.
>
> Terran McCanna
> PINES Program Manager
> Georgia Public Library Service
> tmcca...@georgialibraries.org
>
> * The GPLS office is in the midst of relocating offices. We may be reached
> by all of the current mechanisms during the transition, but to ensure the
> most prompt response, please use the Help Desk:
> https://help.georgialibraries.org
>
>
> On Fri, Aug 3, 2018 at 4:58 PM, Jane Sandberg 
> wrote:
>>
>> Hi all,
>>
>> We have several bookbags that we use to keep track of books for a
>> particular assignment.  We particularly like being able to direct
>> students to a link that includes a nice HTML display of all the books
>> in that bookbag.
>>
>> We typically add books to those bookbags at the point they are
>> cataloged.  However, the staff client doesn't make it easy for
>> catalogers to add to those bookbags at the point of cataloging.  Since
>> the btype column in the container.biblio_record_entry_bucket table =
>> 'bookbag', catalogers can't go to the bib record, click "Other
>> Actions", and use "Add to Bucket".  Instead, they have to:
>> 1) Note the TCN of the book they are cataloging
>> 2) Look up the ID of the bookbag in a document and open it
>> 3) Look up the book by TCN in the Record Bucket Query interface
>> 4) Add the book to the bucket
>>
>> It's really round-about!  If I change the btype to 'staff_client',
>> then the catalogers can suddenly use "Other Actions" > "Add to Bucket"
>> from the catalog record.  It's way easier, but it means that we can no
>> longer see the bookbags in our catalog at the URL
>>
>> https://libcat.linnbenton.edu/eg/opac/results?bookbag=[bookbag_id_goes_here]
>>
>> Does anybody have any suggestions about how we can have our cake (i.e.
>> get nice, public-facing HTML displays of bookbags) and eat it too
>> (i.e. a less onerous process for catalogers to add the books they are
>> cataloging to those bookbags)?  Is there any particular reason that
>> non-bookbag record buckets can't have that nice HTML display in the
>> OPAC too?
>>
>> Thanks,
>>
>>   -Jane
>>
>>
>> --
>> Jane Sandberg
>> Electronic Resources Librarian
>> Linn-Benton Community College
>> sand...@linnbenton.edu / 541-917-4655
>> Pronouns: she/her/hers
>
>



-- 
Jane Sandberg
Electronic Resources Librarian
Linn-Benton Community College
sand...@linnbenton.edu / 541-917-4655
Pronouns: she/her/hers

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] 3.2 Notes on browser client settings moving to server

[Bill Erickson]

On Fri, Aug 3, 2018 at 3:13 PM Kathy Lussier  wrote:

> Hi Bill,
>
> 2. A workstation setting can be turned into a user setting by creating a
>> matching user setting type (same setting name) and removing the workstation
>> setting type.  Such settings will follow the logged user account instead of
>> the workstation.
>
>
> Can we assume the opposite is true too? While testing, I was thinking that
> some sites may prefer the copy templates to be a workstation setting
> instead of a user setting.
>

Yes, with minor code changes.

The code that's loading the copy templates is specifically requesting user
setting values.  If that code were changed to use the new
user-or-workstation-or-yaous API, the existing user setting could be
migrated to a workstation setting.  Ditto the code that applies the values.

Generally speaking, we now have:

1. API to set and get user setting values
2. API to get and get org unit setting values
3. NEW API to get org-or-user-or-workstation setting values, depending on
configuration, context, and available data.
4. NEW API to set user-or-workstation setting values,  depending on
configuration.

I generally refer to the new stuff (#3 and #4) as Cascade Settings.  Any
existing user or org unit setting can be used as a Cascade Setting, if the
caller simply uses the new APIs to manage the code.  (Though, only user and
workstation settings can have values applied via the new API).

-b

Re: [OPEN-ILS-GENERAL] Bookbags and record buckets: having my cake and eating it too?

[Terran McCanna]

I thought there was a wishlist ticket in launchpad for something like this,
but I'm not finding it now - but +1 from me.

Terran McCanna
PINES Program Manager
Georgia Public Library Service
tmcca...@georgialibraries.org

* The GPLS office is in the midst of relocating offices. We may be reached
by all of the current mechanisms during the transition, but to ensure the
most prompt response, please use the Help Desk:
https://help.georgialibraries.org


On Fri, Aug 3, 2018 at 4:58 PM, Jane Sandberg 
wrote:

> Hi all,
>
> We have several bookbags that we use to keep track of books for a
> particular assignment.  We particularly like being able to direct
> students to a link that includes a nice HTML display of all the books
> in that bookbag.
>
> We typically add books to those bookbags at the point they are
> cataloged.  However, the staff client doesn't make it easy for
> catalogers to add to those bookbags at the point of cataloging.  Since
> the btype column in the container.biblio_record_entry_bucket table =
> 'bookbag', catalogers can't go to the bib record, click "Other
> Actions", and use "Add to Bucket".  Instead, they have to:
> 1) Note the TCN of the book they are cataloging
> 2) Look up the ID of the bookbag in a document and open it
> 3) Look up the book by TCN in the Record Bucket Query interface
> 4) Add the book to the bucket
>
> It's really round-about!  If I change the btype to 'staff_client',
> then the catalogers can suddenly use "Other Actions" > "Add to Bucket"
> from the catalog record.  It's way easier, but it means that we can no
> longer see the bookbags in our catalog at the URL
> https://libcat.linnbenton.edu/eg/opac/results?bookbag=[
> bookbag_id_goes_here]
>
> Does anybody have any suggestions about how we can have our cake (i.e.
> get nice, public-facing HTML displays of bookbags) and eat it too
> (i.e. a less onerous process for catalogers to add the books they are
> cataloging to those bookbags)?  Is there any particular reason that
> non-bookbag record buckets can't have that nice HTML display in the
> OPAC too?
>
> Thanks,
>
>   -Jane
>
>
> --
> Jane Sandberg
> Electronic Resources Librarian
> Linn-Benton Community College
> sand...@linnbenton.edu / 541-917-4655
> Pronouns: she/her/hers
>

[OPEN-ILS-GENERAL] Bookbags and record buckets: having my cake and eating it too?

[Jane Sandberg]

Hi all,

We have several bookbags that we use to keep track of books for a
particular assignment.  We particularly like being able to direct
students to a link that includes a nice HTML display of all the books
in that bookbag.

We typically add books to those bookbags at the point they are
cataloged.  However, the staff client doesn't make it easy for
catalogers to add to those bookbags at the point of cataloging.  Since
the btype column in the container.biblio_record_entry_bucket table =
'bookbag', catalogers can't go to the bib record, click "Other
Actions", and use "Add to Bucket".  Instead, they have to:
1) Note the TCN of the book they are cataloging
2) Look up the ID of the bookbag in a document and open it
3) Look up the book by TCN in the Record Bucket Query interface
4) Add the book to the bucket

It's really round-about!  If I change the btype to 'staff_client',
then the catalogers can suddenly use "Other Actions" > "Add to Bucket"
from the catalog record.  It's way easier, but it means that we can no
longer see the bookbags in our catalog at the URL
https://libcat.linnbenton.edu/eg/opac/results?bookbag=[bookbag_id_goes_here]

Does anybody have any suggestions about how we can have our cake (i.e.
get nice, public-facing HTML displays of bookbags) and eat it too
(i.e. a less onerous process for catalogers to add the books they are
cataloging to those bookbags)?  Is there any particular reason that
non-bookbag record buckets can't have that nice HTML display in the
OPAC too?

Thanks,

  -Jane


-- 
Jane Sandberg
Electronic Resources Librarian
Linn-Benton Community College
sand...@linnbenton.edu / 541-917-4655
Pronouns: she/her/hers

Re: [OPEN-ILS-GENERAL] 3.2 Notes on browser client settings moving to server

[Kathy Lussier]

Hi Bill,

2. A workstation setting can be turned into a user setting by creating a
> matching user setting type (same setting name) and removing the workstation
> setting type.  Such settings will follow the logged user account instead of
> the workstation.


Can we assume the opposite is true too? While testing, I was thinking that
some sites may prefer the copy templates to be a workstation setting
instead of a user setting.

Thanks for your work on this!

Kathy

-- 
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128kluss...@masslnc.org


On Fri, Aug 3, 2018 at 2:23 PM, Bill Erickson  wrote:

> Hi All,
>
> With special thanks to Kathy Lussier (and Chris Sharp),
> https://bugs.launchpad.net/evergreen/+bug/1750894 was merged to master
> today.  This change moves persistent browser client preferences / settings
> out of the browser (localStorage / Hatch) to the server.  With this,
> preferences and settings will persist across browser sessions and be
> shareable across multiple browsers.  Clearing localStorage will no longer
> delete preference values.
>
> This code will impact administration and development of new features.  I
> wanted to review some of those here since it might impact active
> development.
>
> Developers
>
> 1. New browser client settings/preferences that should persist across
> browser sessions require a DB upgrade script to add the needed rows to
> config.worksation_setting_type.
>
> 2. Settings that should only be stored locally (e.g. last retrieved
> patron) should be stored using hatch.setLocalItem / getLocalItem or the key
> prefix should be added to the list of special prefixes in hatch.js =>
> service.browserOnlyPrefixes.
>
> 3. Beware that storing preferences on the server means more API calls are
> needed to load the data.  Whenever possible, make use of the
> hatch.getItemBatch call to condense lookups into fewer API calls.
>
> Admins
>
> 1. Migration from browser storage to server storage should happen
> seamlessly as each setting is accessed using the new code.
>
> 2. A workstation setting can be turned into a user setting by creating a
> matching user setting type (same setting name) and removing the workstation
> setting type.  Such settings will follow the logged user account instead of
> the workstation.
>
> 3. No setting can be both a workstation and user setting.  They are
> mutually exclusive.
>
> 4. Org settings with the same name as a user/workstation setting act as a
> fall-through value.
>
> 5. Org setting types that match a browser preference/setting where no
> user/workstation setting type exists (or has been deleted) act as a
> read-only configuration for the setting.  This can be useful, for example,
> for applying a grid display configuration that cannot be changed by staff.
>
> There are more UI improvements to make for this feature, especially for
> managing org unit settings, but I wanted everyone to be aware the pieces
> are in place to do these things on the back-end.
>
> -b
>
>
>

Re: [OPEN-ILS-GENERAL] 3.2 Notes on browser client settings moving to server

[Benjamin Kalish]

Fantastic news!

Benjamin Kalish
Forbes Library / 413-587-1012 / bkal...@forbeslibrary.org

Support Forbes Library:

   - Consider giving a gift  to Forbes
   Library
   - Vote for the Friends of Forbes in the Florence Bank Community Grant
   Program .
   - Join the Friends the Forbes today !


Currently reading: *War on Peace: The End of Diplomacy and the Decline of
American Influence *by Ronan Farrow
Just Finished: *Hunger: A Memoir of (My) Body *by Roxane Gay
For information about accessibility at the library, please see:
http://forbeslibrary.org/accessibility/









On Fri, Aug 3, 2018 at 2:23 PM, Bill Erickson  wrote:

> Hi All,
>
> With special thanks to Kathy Lussier (and Chris Sharp),
> https://bugs.launchpad.net/evergreen/+bug/1750894 was merged to master
> today.  This change moves persistent browser client preferences / settings
> out of the browser (localStorage / Hatch) to the server.  With this,
> preferences and settings will persist across browser sessions and be
> shareable across multiple browsers.  Clearing localStorage will no longer
> delete preference values.
>
> This code will impact administration and development of new features.  I
> wanted to review some of those here since it might impact active
> development.
>
> Developers
>
> 1. New browser client settings/preferences that should persist across
> browser sessions require a DB upgrade script to add the needed rows to
> config.worksation_setting_type.
>
> 2. Settings that should only be stored locally (e.g. last retrieved
> patron) should be stored using hatch.setLocalItem / getLocalItem or the key
> prefix should be added to the list of special prefixes in hatch.js =>
> service.browserOnlyPrefixes.
>
> 3. Beware that storing preferences on the server means more API calls are
> needed to load the data.  Whenever possible, make use of the
> hatch.getItemBatch call to condense lookups into fewer API calls.
>
> Admins
>
> 1. Migration from browser storage to server storage should happen
> seamlessly as each setting is accessed using the new code.
>
> 2. A workstation setting can be turned into a user setting by creating a
> matching user setting type (same setting name) and removing the workstation
> setting type.  Such settings will follow the logged user account instead of
> the workstation.
>
> 3. No setting can be both a workstation and user setting.  They are
> mutually exclusive.
>
> 4. Org settings with the same name as a user/workstation setting act as a
> fall-through value.
>
> 5. Org setting types that match a browser preference/setting where no
> user/workstation setting type exists (or has been deleted) act as a
> read-only configuration for the setting.  This can be useful, for example,
> for applying a grid display configuration that cannot be changed by staff.
>
> There are more UI improvements to make for this feature, especially for
> managing org unit settings, but I wanted everyone to be aware the pieces
> are in place to do these things on the back-end.
>
> -b
>
>
>

[OPEN-ILS-GENERAL] 3.2 Notes on browser client settings moving to server

[Bill Erickson]

Hi All,

With special thanks to Kathy Lussier (and Chris Sharp),
https://bugs.launchpad.net/evergreen/+bug/1750894 was merged to master
today.  This change moves persistent browser client preferences / settings
out of the browser (localStorage / Hatch) to the server.  With this,
preferences and settings will persist across browser sessions and be
shareable across multiple browsers.  Clearing localStorage will no longer
delete preference values.

This code will impact administration and development of new features.  I
wanted to review some of those here since it might impact active
development.

Developers

1. New browser client settings/preferences that should persist across
browser sessions require a DB upgrade script to add the needed rows to
config.worksation_setting_type.

2. Settings that should only be stored locally (e.g. last retrieved patron)
should be stored using hatch.setLocalItem / getLocalItem or the key prefix
should be added to the list of special prefixes in hatch.js =>
service.browserOnlyPrefixes.

3. Beware that storing preferences on the server means more API calls are
needed to load the data.  Whenever possible, make use of the
hatch.getItemBatch call to condense lookups into fewer API calls.

Admins

1. Migration from browser storage to server storage should happen
seamlessly as each setting is accessed using the new code.

2. A workstation setting can be turned into a user setting by creating a
matching user setting type (same setting name) and removing the workstation
setting type.  Such settings will follow the logged user account instead of
the workstation.

3. No setting can be both a workstation and user setting.  They are
mutually exclusive.

4. Org settings with the same name as a user/workstation setting act as a
fall-through value.

5. Org setting types that match a browser preference/setting where no
user/workstation setting type exists (or has been deleted) act as a
read-only configuration for the setting.  This can be useful, for example,
for applying a grid display configuration that cannot be changed by staff.

There are more UI improvements to make for this feature, especially for
managing org unit settings, but I wanted everyone to be aware the pieces
are in place to do these things on the back-end.

-b