| 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 |
opensrfip-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 |
