| Time |
Nick |
Message |
| 06:01 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-06/2022-06-01_04:00:02/test.49.html> |
| 07:17 |
|
rjackson_isl_hom joined #evergreen |
| 07:50 |
|
RFrasur joined #evergreen |
| 09:00 |
|
mmorgan joined #evergreen |
| 09:14 |
|
bgillap joined #evergreen |
| 09:19 |
|
collum joined #evergreen |
| 09:31 |
mmorgan |
How have others set up org units for lockers? What ou type? And how do staff know that the item is for locker pickup, do the items just go in transit to the locker? |
| 09:38 |
jeff |
if the locker is an org unit and set as the pickup library for the hold and you haven't configured otherwise (various "don't transit items for these org units" settings), yes. |
| 09:46 |
mmorgan |
jeff: Thanks, I'm familiar with the settings, just trying to figure out the best choices :) Are some folks not using an org unit for lockers? |
| 09:51 |
|
jvwoolf joined #evergreen |
| 09:57 |
jeff |
We're not currently using lockers, so I haven't given a lot of thought to this, but an org unit, a user setting, and/or "behind desk" hold pickup are some of the options that had come to mind. |
| 09:57 |
jeff |
that is, assuming you aren't doing "all holds in lockers at this branch" |
| 09:59 |
jeff |
I was trying to avoid having per-hold preferences for locker no-locker, but was considering how useful it might be to have an attribute for "this holds item is in a locker" |
| 09:59 |
berick |
mmorgan: we're using org units w/ regular branch OU types |
| 10:13 |
* mmorgan |
got pulled away for a moment |
| 10:13 |
mmorgan |
printing-- |
| 10:14 |
mmorgan |
berick: Thanks, I was leaning toward that, but wondered if I was missing something. |
| 10:15 |
mmorgan |
jeff: We want folks to be able to set the locker as a preferred pickup location. |
| 10:16 |
* mmorgan |
was wondering about setting the branch as the parent of the locker org unit. |
| 10:20 |
jeff |
berick: so Treeville Branch Library and Treeville Branch Library Pickup Lockers are siblings, not parent/child? |
| 10:22 |
|
javier_guel joined #evergreen |
| 10:24 |
berick |
jeff: exactly. was just simpler for us, moreso with a 3rd party catalog. i expect parent/child would work fine, though. |
| 10:26 |
* mmorgan |
dislikes that no matter how the org unit is set, it still appears as a choice when searching the catalog :-/ |
| 10:27 |
javier_guel |
Hi all, I am triying to upgrade to 3.7.0v and I am in the Database Upgrade Procedure, but I'm realizing that my metabib.keyword_field_entry, metabib.identifier_field_entry, metabib.series_field_entry, metabib.subject_field_entry, metabib.author_field_entry and metabib.title_field_entry tables are empty, Is there an script to reingest the records |
| 10:27 |
javier_guel |
into these tables? |
| 10:28 |
|
Dyrcona joined #evergreen |
| 10:30 |
berick |
mmorgan: i bet a patch to modify the catalog to display an org unit in the pickup lib org selector even if the org is opac_visible=false would be pretty simple |
| 10:38 |
mmorgan |
berick: That would be quite useful for the public catalog! ... but there's still bug 1910773 in the staff catalog. |
| 10:38 |
pinesol |
Launchpad bug 1910773 in Evergreen "Staff Catalog does not observe OPAC Visible org unit attribute" [Undecided,New] https://launchpad.net/bugs/1910773 |
| 10:40 |
berick |
mmorgan: that bug surprises me. looking at the code, the XUL client ignored that flag as well. |
| 10:41 |
berick |
since it's not a public catalog |
| 10:42 |
mmorgan |
berick: But the xul client used the public catalog for staff, right? |
| 10:43 |
berick |
it did, but there's there's a check in the code for "is_staff" when determining whether to honor that flag |
| 10:43 |
berick |
specifically: NEXT IF !visible AND inherited_vis AND !ctx.is_staff; |
| 10:45 |
berick |
should be testable using the Traditional catalog in the browser client |
| 10:48 |
JBoyer |
:( Just missed javier, was going to mention pingest.pl' |
| 10:48 |
|
javier_guel joined #evergreen |
| 10:48 |
jeff |
now's your chance. :-) |
| 10:48 |
JBoyer |
Ah, was just typing the @later. :D |
| 10:49 |
JBoyer |
javier_guel, there's a script called pingest.pl that can "reingest" all of your records and populate those tables (and others) |
| 10:49 |
JBoyer |
it's included in Evergreen and should be in /openils/bin/pigest.pl |
| 10:50 |
berick |
mmorgan: yeah, i'm seeing hidden orgs in the Traditional catalog in the browser client that are not visible in the plain (non staff) catalog. |
| 10:50 |
JBoyer |
You'll want to use --help to see what options it has, but just giving it the connection information for your database may be enough to get started. |
| 10:51 |
mmorgan |
berick: Using the Traditional catalog in the web client in our production system (tpac), I do NOT see any org units with opac visible set to FALSE. The global flag mentioned in the bug is also respected. |
| 10:53 |
* berick |
sets flag, restarts |
| 10:55 |
* mmorgan |
fires up a vm |
| 10:56 |
berick |
mmorgan: odd, i'm still seeing hidden orgs in the Traditional catalog in the browser client |
| 11:00 |
berick |
just hiding 'Example Sub-library 1' |
| 11:04 |
javier_guel |
tks, letme try it |
| 11:08 |
mmorgan |
Hmm. Also not seeing them hidden in the traditional catalog on my vm. |
| 11:08 |
* mmorgan |
scratches head. |
| 11:18 |
mmorgan |
The org unit display is one of the main issues our users have with the new staff catalog. |
| 11:20 |
berick |
mmorgan: https://bugs.launchpad.net/evergreen/+bug/1277194 |
| 11:20 |
pinesol |
Launchpad bug 1277194 in Evergreen "Evergreen needs a way to completely hide closed/defunct library units" [Wishlist,Confirmed] |
| 11:23 |
mmorgan |
berick: Thanks, I'm aware of that one too. That would be a nice feature. |
| 11:27 |
berick |
mmorgan: just reinforcing the point that the new staff catalog behaves the same as the old staff catalog in this regard. |
| 11:28 |
berick |
i wonder if there's more to it than just opac_visible=true/false |
| 11:30 |
berick |
oh, custom org trees |
| 11:31 |
|
javier_guel joined #evergreen |
| 11:31 |
berick |
can confirm the Angular catalog does not look at custom org trees |
| 11:37 |
|
jihpringle joined #evergreen |
| 11:46 |
* mmorgan |
is scouring configs and settings. |
| 11:46 |
mmorgan |
berick: fwiw, we don't use custom org trees, but good to know! |
| 12:06 |
mmorgan |
berick: I stand corrected! We do have a custom org tree! |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:17 |
berick |
aha |
| 12:19 |
mmorgan |
Also our System org units are not opac visible unless they have more than one branch. |
| 12:29 |
jeff |
meaning you have visible children whose parents are not-visible? |
| 12:30 |
jeff |
that might be breaking some assumption/optimization somewhere also. |
| 12:39 |
|
jihpringle joined #evergreen |
| 12:45 |
jvwoolf |
mmorgan: jeff: We have it set that way also. There is an "org units do not inherit visibility" global flag. |
| 12:45 |
|
collum joined #evergreen |
| 12:48 |
mmorgan |
jeff: Yes, the idea is, for single branch libraries, searching the system is no different than searching the branch. The extra "system" level adds clutter and confusion |
| 14:14 |
jeff |
I wasn't questioning the practice. :-) |
| 14:14 |
jeff |
I was pointing it out as something that might violate some assumptions somewhere. Bugs lurking, so to speak. I had forgotten about that global flag. |
| 14:20 |
* mmorgan |
nods |
| 14:31 |
RFrasur |
miker++ #outreach committee celebrates you. I celebrate you. w00t! |
| 14:31 |
rhamby_ |
miker++ better late than never! |
| 14:31 |
mmorgan |
miker++ |
| 14:32 |
jweston_ |
miker++ more celebration of 3.9 announcement from outreach! |
| 14:34 |
miker |
if only I'd done it a month ago! :P |
| 14:36 |
RFrasur |
Psh |
| 14:36 |
rhamby_ |
blame the bunnies |
| 14:37 |
miker |
rhamby_: it must be bunnies, yes. |
| 14:37 |
miker |
... twitchy little noses ... |
| 14:38 |
mmorgan |
... and rabbit holes. |
| 15:20 |
|
jihpringle joined #evergreen |
| 15:53 |
|
jvwoolf left #evergreen |
| 16:44 |
jeff |
miker++ |
| 16:45 |
jeff |
(and now I have music stuck in my head) |
| 17:09 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-06/2022-06-01_16:00:02/test.49.html> |
| 18:29 |
|
jihpringle joined #evergreen |
