| Time |
Nick |
Message |
| 04:56 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:57 |
|
kmlussier joined #evergreen |
| 07:03 |
kmlussier |
@coffee |
| 07:03 |
* pinesol_green |
brews and pours a cup of Sumatra Lintong, and sends it sliding down the bar to kmlussier |
| 07:15 |
|
Callender joined #evergreen |
| 07:41 |
|
rjackson-isl joined #evergreen |
| 08:01 |
|
mdriscoll joined #evergreen |
| 08:12 |
|
akilsdonk joined #evergreen |
| 08:13 |
|
mrpeters joined #evergreen |
| 08:20 |
|
phasefx joined #evergreen |
| 08:21 |
|
mtate joined #evergreen |
| 08:50 |
|
dkyle joined #evergreen |
| 08:50 |
|
mmorgan joined #evergreen |
| 08:54 |
|
kbeswick joined #evergreen |
| 08:54 |
|
dkyle left #evergreen |
| 09:00 |
|
ericar joined #evergreen |
| 09:01 |
|
dkyle joined #evergreen |
| 09:15 |
|
bbqben joined #evergreen |
| 09:19 |
|
rjackson_isl joined #evergreen |
| 09:27 |
|
montgoc1 joined #evergreen |
| 09:46 |
|
denishpatel joined #evergreen |
| 09:46 |
|
collum joined #evergreen |
| 09:48 |
|
jboyer-isl joined #evergreen |
| 09:59 |
dbs |
eeevil: hey, should bug 1125621 be linked from & closed from whatever bugs the icons project / CRA/MVF stuff came into being from |
| 09:59 |
pinesol_green |
Launchpad bug 1125621 in Evergreen "RDA 336, 337 338 fields" (affected: 7, heat: 42) [Medium,Confirmed] https://launchpad.net/bugs/1125621 |
| 10:06 |
|
ericar_ joined #evergreen |
| 10:08 |
|
yboston joined #evergreen |
| 10:08 |
|
atlas__ joined #evergreen |
| 10:08 |
|
phasefx joined #evergreen |
| 10:11 |
dbs |
yboston: finally took a look at those RDA records--great start! We also need some that have multiple 264 fields, too, to really exercise our tests, but that's going to be more work (trawling through records to find candidates) |
| 10:13 |
yboston |
dbs: I was planning on writing the cataloging list to ask for more non-OCLC records (while we confirm what we can do with OCLC records) |
| 10:13 |
dbs |
Also, today I learned that "Slackers" is a valid LCSH heading, thanks to Pineapple Express: id.loc.gov/authorities/subjects/sh2005006709.html |
| 10:14 |
yboston |
:) |
| 10:14 |
|
remingtron joined #evergreen |
| 10:14 |
|
dluch joined #evergreen |
| 10:16 |
bshum |
dbwells: Oops, https://bugs.launchpad.net/evergreen/+bug/1310283 seems to indicate that when we messed with the quest_for_knowledge, something may have gotten lost. I pointed it at 2.6.1 for further review. I'll take a closer look later this afternoon if someone else doesn't get there first. |
| 10:16 |
pinesol_green |
Launchpad bug 1310283 in Evergreen "Z39.50 Local Catalog Search Needs "Staff" Flag" (affected: 1, heat: 6) [Medium,Confirmed] |
| 10:16 |
bshum |
tsbere++ |
| 10:28 |
|
remingtron joined #evergreen |
| 10:32 |
dbs |
yboston: oddly enough that Pineapple Express record has a 260 instead of a 264 :/ |
| 10:32 |
dbs |
040 $e rda-ish # :) |
| 10:33 |
yboston |
dbs: I might have added the wrong RDA record for Pinaple express. I had more than one, and I had one of the catalogers here tell me which records to avoid |
| 10:33 |
yboston |
dbs: I can look at what I have again |
| 10:34 |
dbs |
yboston: sure; fwiw that record does have 040 $e rda, so LoC is claiming it's RDA |
| 10:34 |
dbs |
le sigh |
| 10:35 |
yboston |
dbs: that was the hard lesson for me, I got about 11 diverse RDA records, but it turns out they were probably made beofre the 264 tag was preffered tot he 260 :( |
| 10:35 |
|
kbeswick joined #evergreen |
| 10:37 |
dbs |
yboston: yeah, well... we need to handle all the variations (MARC21, RDA transitional, RDA modern), and having Pineapple Express in our demo records is kind of awesome :) |
| 10:40 |
|
ldwhalen joined #evergreen |
| 10:44 |
|
ericar joined #evergreen |
| 10:51 |
phasefx |
the qatests error earlier, looks like a race condition during services startup? |
| 10:52 |
dbwells |
bshum: tsbere's fix for bug 1310283 looks fine to me. Thanks, guys. |
| 10:52 |
pinesol_green |
Launchpad bug 1310283 in Evergreen "Z39.50 Local Catalog Search Needs "Staff" Flag" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1310283 |
| 10:52 |
dbs |
yboston: oh hey, did you want "yamil yamil.com" as your author / sign-off for the RDA records? |
| 10:53 |
|
krvmga joined #evergreen |
| 10:53 |
yboston |
dbs: yes |
| 10:54 |
kmlussier |
tsbere++ |
| 10:54 |
kmlussier |
yboston++ dbs++ |
| 11:00 |
|
jwoodard joined #evergreen |
| 11:06 |
|
kmlussier joined #evergreen |
| 11:09 |
|
bbqben joined #evergreen |
| 11:28 |
eeevil |
dbs: re 1125621, ISTM that the OPs original goal of 33X usage wasn't directly addressed ... so, I dunno, maybe a new bug targetting RDA-ish seed data? I don't have a stron opinion |
| 11:30 |
dbs |
eeevil: thanks. The CRAD/MVF/icons stuff is still pretty fuzzy to me so if you could provide some pointers on that bug, it would be hella-helpful (hella-pful?) |
| 11:34 |
eeevil |
dbs: certainly. one of the questions raised in the bug is a point to consider, though -- do we worry about relator codes, relator text, both, or something else? (btw, this also got me thinking about 008/lang vs 040/lang, and right-click menus for tag/sf in addition to fixed fields) |
| 11:36 |
eeevil |
(if, that is, it's useful to tackle un-fuzzing through a practical use case) |
| 11:38 |
dbs |
We have to worry about both relator codes and relator text, right? |
| 11:39 |
dbs |
There has been a push on the RDA side for relator text, which is a bit crazy for anyone running either a multilingual system or a system that wants to interchange machine-readable data :/ |
| 11:42 |
|
bbqben joined #evergreen |
| 11:42 |
eeevil |
because of reasons, I'm sure... :| |
| 11:49 |
dbs |
oddly, RDA has also pushed for completely oblique IDs for their linked data because they want to support multilingual developers |
| 11:50 |
|
dconnor joined #evergreen |
| 11:51 |
jeff |
different people working on different parts of the spec without enough communication / shared goals? |
| 11:51 |
jeff |
seems odd, yet at the same time so familiar. |
| 11:52 |
eeevil |
I imagine we want to internally collapse the code and text into a single set of values |
| 11:52 |
eeevil |
centered on the code version |
| 11:52 |
jeff |
the wheel of standards turn and specifications come and pass, leaving memories that become technical debt. |
| 11:52 |
jeff |
needs work. |
| 11:53 |
dbs |
the centre of requirements will not hold |
| 12:05 |
eeevil |
dbs: there are several ways to address 33Xab. xpath that extracts both at the same time + normalizer to turn text into code + 1 ccvm set; separate attrs (with separate ccvm entries) that directly extract each value + a composite attr that combines them (this could, in the future, support context menus); variants on either of those. |
| 12:06 |
eeevil |
all have varying tradeoffs of maintenance complexity of the seed data, configuration complexity for admins, code complexity for developers (normalizer development, etc) |
| 12:08 |
eeevil |
so ... the path is WIDE OPEN right now ;) ... the second (separate direct attrs + a third composite) is the most direct, I think. pure seed data (given a full, authoritative code/text relator list file) |
| 12:11 |
dbs |
mmm, TSV alternate format at the very bottom of id.loc.gov/vocabulary/relators.html |
| 12:12 |
dbs |
apparently that's the reconciled list: www.loc.gov/marc/annmarcrdarelators.html |
| 12:12 |
eeevil |
I'd be happy to be the 'murcin that commits that to the repo, as it's public domain for me, for the benefit of all ... anyone have a preferred location in the source tree? |
| 12:18 |
yboston |
@bug 1125621 |
| 12:18 |
pinesol_green |
yboston: I see nothing, I know nothing! |
| 12:18 |
yboston |
bug 1125621 |
| 12:18 |
pinesol_green |
Launchpad bug 1125621 in Evergreen "RDA 336, 337 338 fields" (affected: 7, heat: 42) [Medium,Confirmed] https://launchpad.net/bugs/1125621 |
| 12:19 |
|
tspindler joined #evergreen |
| 12:19 |
eeevil |
I guess it's too much to ask to have a single tsv with every one of those code listings ... |
| 12:20 |
dbs |
eeevil: huh. there's more than the 268? |
| 12:20 |
eeevil |
http://www.loc.gov/standards/sourcelist/ those... |
| 12:21 |
dbs |
oh, god |
| 12:22 |
eeevil |
with that we could populate ALL THE THINGS |
| 12:24 |
dbs |
I guess the $2 is less of a concern in some ways, but it would be helpful for linking-out purposes (e.g. if $2 marccountry then uri = 'http://id.loc.gov/vocabulary/countries/' + $a) |
| 12:24 |
eeevil |
basically, a machine readable (HA!) version of the data behind http://www.loc.gov/marc/sourcelist/index.html#bibliographic |
| 12:27 |
eeevil |
the rda{carrier|content|media} tables hidden behind links on http://www.loc.gov/standards/sourcelist/genre-form.html look useful |
| 12:38 |
pinesol_green |
[evergreen|Mike Rylander] Grab an up-to-date relator code list. Thanks, LoC! - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4128a12> |
| 12:40 |
|
jihpringle joined #evergreen |
| 13:08 |
jl- |
eeevil: what were you telling me about yesterday with 2.6 and separate library scope search? |
| 13:13 |
|
ldwhalen joined #evergreen |
| 13:17 |
|
ericar joined #evergreen |
| 13:19 |
kmlussier |
yboston++ |
| 13:20 |
kmlussier |
yboston: Thanks for your help with the conference presentations! |
| 13:24 |
phasefx |
yboston++ |
| 13:25 |
phasefx |
the website looks to be straining at the moment :) |
| 13:26 |
kmlussier |
@karma yboston |
| 13:26 |
kmlussier |
Where did pinesol_green go? |
| 13:27 |
jeff |
lupin's apparently down. |
| 13:27 |
bshum |
Poor lupin |
| 13:28 |
bshum |
Must be people all jumping on the presentations :) |
| 13:31 |
|
serflog joined #evergreen |
| 13:31 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 13:43 |
|
serflog joined #evergreen |
| 13:43 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 13:43 |
jl- |
I do have an org unit named SHIP |
| 13:43 |
jl- |
but it's still showing all records, how can I limit it to only records with that subfield |
| 13:44 |
csharp |
I pulled it down for a minute |
| 13:44 |
kmlussier |
jl-: So you're saying it shows up even when you're not searching SHIP? |
| 13:44 |
bshum |
jl-: Do you still have your bib records marked mostly transcendent? |
| 13:44 |
csharp |
it looks happier now |
| 13:45 |
bshum |
If so, that'll trump any scoping you use, and show all the bibs that are transcendent. |
| 13:45 |
bshum |
You need to change them to not be transcendent anymore. And add real barcoded copies to make the bibs visible in public searches. |
| 13:45 |
kmlussier |
jl-: Yes, you don't want to use transendency with located URI's. You want to use one option or the other. |
| 13:45 |
* csharp |
moves on to other things |
| 13:46 |
jeff |
csharp++ thanks! |
| 13:46 |
csharp |
jeff: bshum: feel free to bug me again if there are further issues ;-) |
| 13:46 |
bshum |
csharp++ |
| 13:48 |
bshum |
I'd be curious if 856 with so limited in details would work properly. I'm thinking about lack of other subfields, like $u for the link |
| 13:48 |
bshum |
I'm not sure what it'll do actually. |
| 13:48 |
|
ldwhalen joined #evergreen |
| 13:50 |
* jeff |
grins as he consults a stackoverflow question that cites an apache wiki page that he's edited |
| 13:50 |
|
bmills joined #evergreen |
| 13:58 |
csharp |
jeff++ |
| 13:59 |
|
ldwhalen joined #evergreen |
| 14:06 |
|
ldwhalen joined #evergreen |
| 14:12 |
|
ldwhalen joined #evergreen |
| 14:14 |
|
finnx joined #evergreen |
| 14:24 |
|
tspindler joined #evergreen |
| 14:43 |
kmlussier |
dbwells: https://bugs.launchpad.net/evergreen/+bug/1078787/comments/2 |
| 14:43 |
pinesol_green |
Launchpad bug 1078787 in Evergreen "Non-compressed serials holdings display shows holdings from all libraries regardless of scope" (affected: 1, heat: 8) [Undecided,Triaged] |
| 14:43 |
kmlussier |
Sorry it took so long to follow up on your question. |
| 14:46 |
kmlussier |
yboston++ # Because pinesol_green wasn't here to record earlier karma points sent in your direcction. :) |
| 14:55 |
|
hbrennan joined #evergreen |
| 14:59 |
|
asimon joined #evergreen |
| 15:01 |
asimon |
What would cause a new out-of-the-box Evergreen system to offer 'Request item' in the staff client TPAC but not the public TPAC? |
| 15:01 |
tsbere |
asimon: No holdable copies, staff member has place unfillable hold permissions? |
| 15:03 |
asimon |
tsbere: All copies are in holdable locations. At least in our other TPACs, the 'Request item' option appears even before the user logs into an account in the public TPAC. |
| 15:03 |
tsbere |
asimon: Are the copies themselves holdable? In holdable statuses? |
| 15:04 |
* tsbere |
wrote some of that code, and while it is fairly simple that means it is also usually fairly easy to spot why it is hiding the link |
| 15:07 |
tsbere |
asimon: If *no* place hold links show up, at all, to the public it may be that the DB doesn't have the code that populates the "we found at least one holdable copy" flag and as such the check against it is returning false |
| 15:08 |
asimon |
tsbere: That's it! All the copies are set to holdable: f. Odd that the staff client allows holds anyway. |
| 15:08 |
tsbere |
asimon: As mentioned, if you have everything permissions or the place unfillable hold permission the staff client will show the place hold links either way. |
| 15:08 |
tsbere |
(really just the latter, but everything covers, well, everything) |
| 15:21 |
|
ldwhalen joined #evergreen |
| 15:24 |
csharp |
alert_helper='history|tail -n1|sed -e "s/^\s*[0-9]\+\s*//" -e "s/;\s*alert$//"' |
| 15:24 |
csharp |
doh! |
| 15:24 |
csharp |
sorry - wrong window |
| 15:24 |
csharp |
"WHATEVER YOU DO, DON'T RUN THAT COMMAND! OMG!" |
| 15:25 |
* csharp |
is just kidding |
| 15:34 |
* jeff |
raises an eyebrow |
| 15:36 |
|
ldwhalen joined #evergreen |
| 15:55 |
Bmagic |
Can anyone lead me down the trail to troubleshooting circulation matrix decision making? |
| 15:55 |
|
dreuther joined #evergreen |
| 15:59 |
csharp |
Bmagic: are you aware of the action.find_circ_matrix_matchpoint function? |
| 15:59 |
Bmagic |
csharp: no I am not |
| 16:01 |
|
tspindler joined #evergreen |
| 16:01 |
csharp |
Bmagic: parameters: context_ou, match_item, match_user, renewal |
| 16:02 |
csharp |
so select action.find_circulation_matrix_matchpoint(ou.id, copy.id, user.id, renewal(t/f)) will show you the ID of the rules that match and the rule that gets chose |
| 16:02 |
csharp |
n |
| 16:03 |
csharp |
that's the best/only troubleshooting tool I know about |
| 16:03 |
Bmagic |
that is very helpful! |
| 16:04 |
csharp |
yeah, I attempted a perl script a while back to make it so you could enter OU shortname, copy barcode, user barcode and renewal t/f and see the rules in plain english, but it got pretty convoluted ;-) |
| 16:05 |
jl- |
bshum kmlussier yes they are still marked as trancendent, should I mark them as source =2 and then located URI's will work? |
| 16:05 |
kmlussier |
jl-: They should as well as you are using all the required subfields for the 856 field. |
| 16:08 |
kmlussier |
jl-: All of the subfields you should be using are identified in http://docs.evergreen-ils.org/1.6/draft/html/electronicresourcesvisible.html |
| 16:08 |
kmlussier |
jl-: And I think it's important to have those initial indicators too. |
| 16:09 |
Bmagic |
csharp: I must be doing something wrong. When I attept the query with the appropriate substitutions, the DB says "function action.find_circulation_matrix_matchpoint(integer, bigint, integer, boolean) does not exist" |
| 16:11 |
Bmagic |
csharp: it seems like it needs an object and not a number |
| 16:12 |
jl- |
Bmagic: hiya |
| 16:12 |
csharp |
Bmagic: what is the output of '\df action.find_circ_matrix_matchpoint' - does it show 2 functions? |
| 16:12 |
kmlussier |
jl-: Yes, you need more data in there. Your first indicator needs to be 4, the second indicator 0. You'll also want a subfield u with the URL and a subfield y with the link text that should display. |
| 16:13 |
Bmagic |
csharp: yes |
| 16:14 |
Bmagic |
csharp: select * from action.find_circulation_matrix_matchpoint(157,1504347::bigint, 200428, false) |
| 16:15 |
Bmagic |
jl-: hiya back! |
| 16:15 |
csharp |
Bmagic: from my script: SELECT action.find_circ_matrix_matchpoint(?::integer, ?::bigint, ?::integer, ?::boolean) |
| 16:15 |
csharp |
so I cast each one |
| 16:15 |
Bmagic |
gotcha |
| 16:16 |
* csharp |
needs to get back to that script - it does represent several hours of labor and learning perl DBI |
| 16:19 |
Bmagic |
csharp: it was a spelling error in the function name |
| 16:19 |
csharp |
Bmagic: ah - cool |
| 16:19 |
jl- |
kmlussier: why do I want a link text? this should be the article title |
| 16:21 |
jl- |
sorry let me just re-explain. I want to have 2-3 different universities in our opac, but ideally limit all their records to a single search so if you click 'Shippensburg' then only ship's records will show (baring in mind, I haven't done any copies nor do I want to for now) |
| 16:21 |
jl- |
which is why I made them all transcendent for now |
| 16:21 |
jl- |
is there any batch solution for single org searching |
| 16:22 |
kmlussier |
jl-: If you make it transendent, then the records will show up in all scopes, so I don't think it will help you in this situation. |
| 16:23 |
jl- |
I understand, can I do any batch editing for the existing records to tag them to a search scope? |
| 16:23 |
dbwells |
csharp: git.evergreen-ils.org is super-duper slow for me right now. Not sure if this is part of the great migration, or even related, but thought I'd give a heads up. |
| 16:23 |
kmlussier |
The way you can define which scope a record shows up in is to a) add copies owned by whichever university owns the item or b) add an 856 field with a subfield 9. I can't think of another way to do it. |
| 16:24 |
kmlussier |
When you scope a search, Evergreen isn't looking at who owns the bib record. It's looking at the copy information. |
| 16:24 |
jl- |
kmlussier: ok, but I also have to add link text which means I can't batch edit |
| 16:24 |
jl- |
because they'll have individual links texts? |
| 16:24 |
csharp |
dbwells: no migration yet, but I'll check it out |
| 16:25 |
dbwells |
csharp: thanks |
| 16:25 |
Bmagic |
csharp++ # thanks for the circ_mod trace tip |
| 16:25 |
csharp |
dbwells: I'm on crappy wifi, so I was assuming that slowness was on my end - thanks for speaking up about it ;-) |
| 16:26 |
jl- |
kmlussier: can I give you a call tomorrow morning |
| 16:26 |
jl- |
or do you prefer lengthy text :) |
| 16:26 |
dbwells |
csharp: I eventually got a password prompt when pulling, but no progress beyond that. It's been sitting there for 3-4 minutes at least. |
| 16:27 |
Bmagic |
Now that I have figured out which rule the system chose, I have a larger issue. We have specific rules to allow patrons to checkout different types of items. Then we have a rule to DENY checkouts for any item located on a certian shelf. If the item getting checked out is in any catagory specified by those other rules, it will be allowed to checkout and the deny rule does not get chosen |
| 16:28 |
kmlussier |
jl-: No, sorry. I'm traveling tomorrow. |
| 16:28 |
csharp |
dbwells: hmm - the server itself is very un-busy |
| 16:28 |
jl- |
kmlussier: ok, how about now? |
| 16:29 |
kmlussier |
jl-: I was mistaken. The subfield y isn't required. But subfield u is. Because you need to tell Evergreen where the electronic resource is. |
| 16:29 |
tsbere |
Bmagic: What is your goal? Stop the items on the shelf from being checked out? |
| 16:29 |
Bmagic |
tsbere: yes, a certain shelf is reserved for staff |
| 16:29 |
tsbere |
Bmagic: And by "shelf" you mean "copy location"? |
| 16:29 |
Bmagic |
tsbere: yes, copy location |
| 16:30 |
|
tspindler left #evergreen |
| 16:30 |
tsbere |
Bmagic: How many other copy location based rules do you have? |
| 16:30 |
kmlussier |
jl-: Normally, I would be more than happy to help over the phone. But I'm tying up loose ends here, and, although I have a good understanding of how Located URI's work, I think others in here will have better ideas for how to batch edit things to get them to work the way you need them to. |
| 16:30 |
Bmagic |
tsbere: none of the other rules contain a copy location (the ones that are getting chose over the deny rule) |
| 16:30 |
kmlussier |
It's just not something I do very often. |
| 16:31 |
tsbere |
Bmagic: I mean *in general* - The easiest solution may be "make copy location the most important weighting factor" |
| 16:31 |
Bmagic |
tsbere: I see, there is something I didnt know about: weights |
| 16:31 |
tsbere |
Bmagic: Otherwise you are going to run into "fill in more details, or create more rules, for the deny part" |
| 16:31 |
jl- |
kmlussier: ok thanks for now |
| 16:32 |
tsbere |
Bmagic: Is the rule that does the deny showing up in the buildrows piece of the finc_circ_matrix_matchpoint output? |
| 16:32 |
Bmagic |
tsbere: yes, it's second |
| 16:33 |
tsbere |
Bmagic: At least it is showing up. To more directly help you I would need dumps of the rules in question. Otherwise I can only throw general advice around at this point. |
| 16:33 |
csharp |
dbwells: hmm - the server looks okay and we're able to git clone the Evergreen.git repo in a timely manner on one of the other servers in the cage |
| 16:33 |
Bmagic |
tsbere: no problem |
| 16:33 |
jl- |
kmlussier: would it be easier to just attach copies |
| 16:34 |
Bmagic |
tsbere: http://pastebin.com/if5JV0JE |
| 16:34 |
csharp |
dbwells: I'm wondering if it was something transient |
| 16:36 |
Bmagic |
tsbere: results of find_circ.... "(t,"(216,t,174,1,Music,,,,,,f,,,,,t,15,102,101,,,,,,,,,,)","{216,231,214}")" |
| 16:36 |
kmlussier |
jl-: I don't think your server is accessible to the outside world. |
| 16:36 |
tsbere |
Bmagic: For sanity purposes, can I get the column headers for that? I don't want to assume they are in the order I would expect them to be in. |
| 16:36 |
kmlussier |
jl-: But, if it's not an electronic resource, I would add copies. |
| 16:36 |
jl- |
kmlussier: it is if you use https |
| 16:37 |
Bmagic |
tsbere: http://pastebin.com/0y7CZzPS |
| 16:37 |
jl- |
can I batch add copies (I'm aware that idealy I would export a copies file from the previous ILS) |
| 16:38 |
kmlussier |
jl-: In that case, then, I would add copies. |
| 16:39 |
jl- |
kmlussier: is there a generic way to do this? without a copies file? |
| 16:40 |
tsbere |
Bmagic: Well, by default, copy_location and circ_modifier are generally equal in weight. As such...I think you might be being hit by "when all else is equal, order by row id". You either need to make your deny rule more specific or increase the weight of copy_location. |
| 16:40 |
kmlussier |
jl-: Probably, but now you've gone beyond my area of expertise. Sorry. I can help with how end users add copies, but that's about as much as I know for adding copies. |
| 16:40 |
jl- |
ok thanks |
| 16:40 |
Bmagic |
tsbere: that is great info! |
| 16:40 |
jl- |
I will be back tomorrow |
| 16:41 |
jl- |
:) |
| 16:41 |
tsbere |
Bmagic: One way to make the deny rule more specific: We split the group tree from "Users" to "Patrons" and "Staff" - Change the deny rule to block at the "Patrons" level will make it more specific, though you may need more for other branches of the group tree if you have them. |
| 16:41 |
kmlussier |
jl-++ #perseverance |
| 16:42 |
jl- |
kmlussier++ #patience |
| 16:42 |
tsbere |
Bmagic: You could also specify something else. "Reference is false" if you never expect reference=true items to be on that shelf |
| 16:43 |
Bmagic |
tsbere: awesome - That gives me lots of idea's - This is a new area for me so I have a lot to learn |
| 16:44 |
tsbere |
Bmagic: Or even something like "is not a renewal" as if you block the initial checkout renewal shouldn't matter |
| 16:44 |
Bmagic |
tsbere: I see what you mean |
| 16:44 |
tsbere |
Or make two entries. "Is not a renewal" and "is a renewal" to cover both cases. Just so long as it is more specific. |
| 16:44 |
Bmagic |
tsbere++ |
| 16:45 |
dbwells |
csharp: I stepped out for a minute, but it seems fine now, thanks for checking. |
| 16:45 |
tsbere |
Bmagic: One of your better options may be to set the copy circ or owning library to 174 |
| 16:46 |
eeevil |
Bmagic: the way I explaiin what tsbere is saying is: the more things you care about, and the more specifically you care about them (branches instead of systems, etc), the more tightly the rule will bind and closely it will match |
| 16:46 |
tsbere |
Bmagic: Utterly harmless if that is a local copy location, or helps with rule sanity if it is a global one and you only want to lock out your own items. |
| 16:48 |
tsbere |
eeevil: Quick question for you: Are you against renaming columns in the circ/hold matrix assuming I can create a view that uses the old names (since data types and such would be changing anyway you would advocate "new table name, make old name a view" from conference discussions if I recall)? |
| 16:49 |
pinesol_green |
[evergreen|Dan Wells] Compile and Tweak Release Notes for 2.6.0 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cfd5d52> |
| 16:51 |
eeevil |
tsbere: it's hard to answer with a hard yes or no, but the goal I'd advocate is for the most backward compat possible. that might look like "duplicate" rows if you unnest an array, say, or it might look like "take the first element of an array as an approximation" if the id is important (likely used elsewhere) |
| 16:53 |
tsbere |
eeevil: In this case my primary is "I want to name columns the same in the circ and hold matrix, which would involve re-naming some 'behind the view'" with a secondary of "a few columns the name would be deceptive after changes and thus I want to come up with new, less deceptive names for them, but the view could still show the old names" |
| 16:56 |
eeevil |
tsbere: to verify I'm understanding, the goal is clarity? |
| 16:59 |
eeevil |
tsbere: so, I had a thought regarding your "groups of org units" use case ... had you considered using the bucket infrastructure, a la search "lassos"? |
| 16:59 |
tsbere |
eeevil: Clarity in one case, consistent naming in the other |
| 17:00 |
tsbere |
eeevil: I considered it, thought about it, and ultimately decided against it as search groupings and circ policy groupings did not seem to be a good fit together |
| 17:01 |
eeevil |
what about having a bucket type specific to circ groups? |
| 17:01 |
eeevil |
IOW, it needn't be exactly lassos |
| 17:01 |
eeevil |
just shaped the same |
| 17:01 |
tsbere |
eeevil: Plus I had decided I didn't want "single org unit buckets" nor two columns nor things like "negative number means go look up a bucket" tricks |
| 17:03 |
eeevil |
hrm... well, making single-OU buckets easy to do via a "streamlined" interface ("select an org" creates a 1-org bucket) would allow the fkey |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:03 |
eeevil |
just a thought |
| 17:04 |
tsbere |
eeevil: Time to go home today. I will see about finishing up some thoughts in my current notes and finding a place to post them soon. |
| 17:04 |
eeevil |
tsbere: thanks! (btw, did you have a chance to test the array-ish pcrud stuff? if you have a sec to answer) |
| 17:04 |
|
bbqben joined #evergreen |
| 17:05 |
tsbere |
eeevil: I haven't tested it fully, but I believe it at least compiled and seemed to return results. I don't recall trying to write with it though. |
| 17:05 |
eeevil |
tsbere: cool. if you hit issues, let me know. I think that may open up some broader improvements where we currently have global_required ... but we'll need to add more general array support... |
| 17:06 |
eeevil |
(array-writing support, I mean) |
| 17:08 |
* eeevil |
skee-daddles |
| 17:12 |
|
jeff_ joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 17:17 |
|
atlas__ joined #evergreen |
| 17:18 |
|
mdriscoll left #evergreen |
| 17:27 |
|
jeff___ joined #evergreen |
| 17:29 |
|
jeff___ joined #evergreen |
| 18:00 |
|
ldwhalen joined #evergreen |
| 19:11 |
|
dcook joined #evergreen |
| 19:18 |
|
kmlussier joined #evergreen |
| 19:36 |
|
kmlussier left #evergreen |
| 20:00 |
|
bbqben joined #evergreen |
| 20:12 |
|
kmlussier joined #evergreen |
| 20:40 |
|
ldwhalen joined #evergreen |
| 20:44 |
|
ldwhalen joined #evergreen |
| 21:17 |
|
dcook joined #evergreen |
| 23:01 |
|
ldwhalen joined #evergreen |
