Evergreen ILS Website

IRC log for #evergreen, 2022-01-04

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
06:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:25 collum joined #evergreen
07:28 rjackson_isl_hom joined #evergreen
08:29 mmorgan joined #evergreen
08:42 mantis joined #evergreen
08:45 rfrasur joined #evergreen
08:51 rfrasur_v2 joined #evergreen
09:08 jvwoolf joined #evergreen
09:47 Bmagic What would cause the OPAC to display parts from other bibs at the place holds parts radio button interface? At first I thought it might* be conjoined bibs, but one of the example parts getting displayed is from a deleted bib.
09:48 Bmagic though the part is not deleted (biblio.monograph_part)
09:54 mmorgan Bmagic: Could items have been transferred from another bib?
09:55 Bmagic ah yes, that's probably it, let me check
09:57 Bmagic Is there a bug when transferring items with parts? When the parts have the same name as some already-existing part labels on the destination bib?
10:08 rhamby there really isn't an assumption that parts should be on the same bib as the copy though we as humans think that way.  I haven't looked but I wouldn't be suprised if items moved between bibs still pointed to a part associated to the old bib.
10:11 Bmagic rhamby: Right, it's technically sound. Though I think we can agree that it's a bug? The staff and patrons are now confused when presented with part choices with all the same name
10:11 rhamby record merging does look for the part lable on the new bib so it at least makes that assumption, should be easy to find any mismatched ones via sql
10:11 rhamby Bmagic: if it's doing that I would classify it as a bug, yeah
10:12 * mmorgan remembers some part bugs, but can't search for them atm
10:12 Bmagic mmorgan: /me currently reading through 178 LP results for "parts"
10:15 Bmagic The deleted bib doesn't have any data in merged_to or merge_date, but it was last updated in 2018.. now I'm trying to figure out which version of Evergreen introduced those columns and whether or not it's possible that these bibs were merged before/after the feature
10:19 Bmagic introduced in 3.1, and the merge happened while the database was on 2.12, so, this was likely a result of bib merge (as opposed to item transfer action)
10:35 Bmagic Just setup two bibs and an item on each with the same part name. Merged them, and Evergreen did the right thing. So it's not a bug on 3.7
10:39 jeff I think it might be an improvement if cancelled holds stayed cancelled, and the "uncancel" operation created a new hold request (potentially with a link to the original).
10:40 Keith-isl joined #evergreen
10:41 jeff Semi-related, I think the addition of shelf_alias or current_shelf_alias (the hold shelf alias at the time the hold came available) might be useful.
10:42 jeff As well as moving default hold alias generation out of a receipt-level function so that it's more easily available to be stuffed in said new column.
11:20 Bmagic jeff++ # mover and a shaker
12:20 jihpringle joined #evergreen
14:43 jeff hardly. :-P
14:45 abowling joined #evergreen
14:47 abowling i'm mostly confident i've overlooked something stupid to cause this. anybody have an idea what i missed on a 3.8.0 upgrade to cause the following error?
14:47 abowling open-ils.cstore ERROR No "datatype" attribute for field "global"
14:48 Bmagic fm_IDL.xml is correct on the brick?
14:49 abowling Bmagic: so far as I know
14:49 Bmagic diff the 3.8.0 git repo OpenILS/examples/fm_IDL.xml against /openils/conf/fm_IDL.xml
14:50 mmorgan autogen?
14:50 Bmagic (and it's in another place for reports) - /openils/var/web/reports/fm_IDL.xml
14:52 abowling opensrf@ip-172-30-0-54:~$ diff /home/opensrf/Evergreen-ILS-3.8​.0/Open-ILS/examples/fm_IDL.xml /openils/conf/fm_IDL.xml
14:52 abowling opensrf@ip-172-30-0-54:~$
14:53 Bmagic groovy
14:53 Bmagic try mmorgan's suggestion. Make sure autogen.sh was ran (with the -u flag once) on the app server
14:54 Bmagic And just double checking but you've ran the SQL upgrade sql code on the database? select * from config.upgrade_log order by install_date desc;
15:08 Keith_isl joined #evergreen
15:51 abowling mystery solved. 3.6.2-3.7.0 didn't complete properly, even though it looked to me like it did. thanks all for chiming in and JBoyer++ for a good recommendation for the next time I do this.
16:10 jvwoolf left #evergreen
16:53 Keith-isl joined #evergreen
17:09 mmorgan left #evergreen
18:02 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
21:52 alynn26_away joined #evergreen
21:52 AFloyd__ joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat