| Time |
Nick |
Message |
| 04:38 |
|
Terence joined #evergreen |
| 04:39 |
Terence |
helo |
| 04:43 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 04:51 |
|
wsmoak joined #evergreen |
| 04:51 |
|
wsmoak joined #evergreen |
| 06:41 |
|
b_bonner joined #evergreen |
| 06:41 |
|
mnsri_ joined #evergreen |
| 06:42 |
|
mtcarlson_away joined #evergreen |
| 07:01 |
|
artunit joined #evergreen |
| 07:55 |
|
rjackson-isl joined #evergreen |
| 08:07 |
|
akilsdonk joined #evergreen |
| 08:27 |
|
mmorgan joined #evergreen |
| 08:27 |
|
Shae joined #evergreen |
| 08:39 |
|
_bott_1 joined #evergreen |
| 08:50 |
|
tspindler joined #evergreen |
| 09:10 |
|
jwoodard joined #evergreen |
| 09:30 |
|
tsbere joined #evergreen |
| 09:32 |
|
tsbere joined #evergreen |
| 09:32 |
bshum |
phasefx: Hmm, looks like the live test build failed with the new DB pre-req makefile targets |
| 09:33 |
|
tsbere joined #evergreen |
| 09:36 |
dbs |
/home/opensrf/Evergreen/Open-ILS/src/extras//install/Makefile.debian-wheezy:8: *** commands commence before first target |
| 09:37 |
dbs |
crap. Missing \ at the end of line 8 |
| 09:37 |
bshum |
Whoops :( |
| 09:37 |
dbs |
live-tests++ |
| 09:38 |
dbs |
prepping a fix |
| 09:39 |
bshum |
dbs++ |
| 09:40 |
bshum |
The other ones look fine, fwiw. |
| 09:41 |
dbs |
Yep, lucky the live tester tests wheezy |
| 09:41 |
dbs |
I'm going to just push the fix in if you don't mind. Just two lines. |
| 09:42 |
bshum |
dbs: Sounds good to me. |
| 09:42 |
bshum |
Thanks! |
| 09:42 |
dbs |
user/dbs/fix_broken_Makefile_install if you want to double-check |
| 09:43 |
dbs |
robbat2 was saying that we don't need gcc in the database prereqs anymore, which is probably true, but an optimization for later. |
| 09:43 |
bshum |
Looks fine to me. |
| 09:43 |
dbs |
pushed |
| 09:45 |
pinesol_green |
[evergreen|Dan Scott] Fix broken prereq installer for debian wheezy - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=768990d> |
| 09:47 |
|
yboston joined #evergreen |
| 09:52 |
|
mrpeters joined #evergreen |
| 09:53 |
|
mrpeters left #evergreen |
| 09:56 |
|
tspindler1 joined #evergreen |
| 10:03 |
csharp |
can I assume that the 'replaces' column in actor.usr_address is used for the "old" address id that it replaced? |
| 10:27 |
jeff |
csharp: replaces is intended to reference another actor.usr_address entry by id, yes. it is used by the "pending" address functionality at a minimum. |
| 10:27 |
jeff |
(and possibly also at a maximum) |
| 10:29 |
csharp |
great |
| 10:29 |
csharp |
we're going to use it to process address updates we're getting from Unique |
| 10:29 |
csharp |
we mark the old one invalid and insert the new one which will now refer to the old one |
| 10:29 |
jeff |
are you working on feeding their machine-readable reports into evergreen in an automated fashion? |
| 10:30 |
csharp |
no, this is a special project - we asked them to clean up/dedupe our patron data |
| 10:30 |
csharp |
specifically, we asked Emerald Data Networks, who have subcontracted to UMS |
| 10:31 |
jeff |
i see. |
| 10:31 |
csharp |
oh, and they're running it through the NCOA database, so if there's a new address, that's what we're adding |
| 10:32 |
jeff |
does your contract specify that they will be releasing the tools they create, or should I not worry about that if that's something we look at doing in the future? |
| 10:33 |
jeff |
or perhaps more simply, "will there be tools releases as part of this work?" |
| 10:33 |
jeff |
released. :P |
| 10:33 |
jeff |
if we take up something like that i'll try to remember to give a holler on list beforehand |
| 10:53 |
csharp |
I'll put whatever I can into the PINES contrib repo |
| 10:54 |
csharp |
UMS tools aren't available to us though |
| 11:23 |
|
wsmoak joined #evergreen |
| 11:23 |
|
wsmoak joined #evergreen |
| 11:31 |
|
ericar joined #evergreen |
| 12:07 |
|
akilsdonk joined #evergreen |
| 12:12 |
|
tspindler joined #evergreen |
| 12:15 |
|
akilsdonk_ joined #evergreen |
| 12:18 |
|
tspindler joined #evergreen |
| 12:19 |
|
tspindler1 joined #evergreen |
| 12:21 |
|
ni947278 joined #evergreen |
| 12:24 |
|
ni947278 left #evergreen |
| 12:25 |
|
buzzy joined #evergreen |
| 12:28 |
|
kmlussier joined #evergreen |
| 12:31 |
|
akilsdonk joined #evergreen |
| 12:46 |
jeff |
interesting. Mac running Windows via Parallels Desktop, 3M RFID pad works with success, software wedge can input values from the tag into something like Notepad, but fails to generate any input in the Evergreen staff client. |
| 12:46 |
jeff |
Has anyone here tried such a convolution before? |
| 12:50 |
tsbere |
jeff: I have seen something like that a few times. one time it was just "evergreen doesn't have focus in the right place" |
| 12:50 |
jeff |
That was one of the first things we checked (and double checked) :-) |
| 12:51 |
jeff |
tsbere++ |
| 12:51 |
tsbere |
jeff: I have also seen the software wedge examining the supposed focus and not being able to tell that there was, in fact, a text input active, or having a list of applications that need focus before it will input into including notepad but not what we want to input into |
| 12:51 |
tsbere |
jeff: Note I dunno what that particular software wedge supports option-wise. The really simple ones don't check anything. ;) |
| 12:52 |
tsbere |
jeff: Oh, and at least once I saw things rigged to hit tab before entering, thus *clearing* focus by jumping to the next field. That was a standard barcode scanner, though. |
| 12:57 |
jeff |
co-worker reports that restarting Evergreen fixed it. odd. |
| 12:58 |
tsbere |
jeff: I know of at least one method of sending keys to things that sometimes gets annoyed if the thing you are sending to was started first. I wouldn't be surprised if they all sometimes get that way....and if the software wedge isn't in admin mode but evergreen *was* for some reason that would also create a similar issue. |
| 12:59 |
jeff |
"in admin mode" in what sense? |
| 12:59 |
jeff |
as in "running in an elevated/UAC windows sense"? |
| 12:59 |
tsbere |
yea |
| 13:00 |
tsbere |
non-elevated processes can't interact with elevated processes in that direction. No keyboard or mouse input can thus be "faked" into them. The opposite direction obviously differs. |
| 13:00 |
kmlussier |
hopkinsju: Thanks for cleaning up the Concerto login page! |
| 13:00 |
kmlussier |
hopkinsju++ |
| 13:01 |
jeff |
we haven't run into problems in other installations with this software wedge and evergreen in terms of which is started first (at least, not this kind of problem), but there's a slight possibility that the client was started from the installer (does the installer offer to start the client? i don't recall), so that could explain things. |
| 13:02 |
tsbere |
jeff: I don't think it prompts to start the client, but I may just be forgetting that it offers. |
| 13:02 |
jeff |
yup, docs.evergreen-ils.org screenshots confirm that the installer offers to start the client. :-) |
| 13:02 |
jeff |
well, the screenshots are for 2.3 (in the 2.6 docs -- huh), but i don't think it's changed significantly since then. |
| 13:02 |
* tsbere |
doesn't actually use the installer all that often personally ;) |
| 13:03 |
jeff |
I'd argue that we probably should disable that offer to start the client. |
| 13:03 |
tsbere |
jeff: So yea, if the installer started the client it was likely in elevated mode, and the software wedge in user mode would be unable to send input to it. |
| 13:04 |
tsbere |
jeff: I dunno, "start the client after install, log in, register workstation, close client once registered" seems fairly decent options-wise to me. <_< |
| 13:04 |
* tsbere |
isn't all that certain that a very large number of people are significantly effected by the client running from the installer *once* with elevated privs |
| 13:05 |
tsbere |
jeff: Figuring out how to tell the installer "when you launch this, tell it to lose admin privs" wouldn't be a bad compromise, though |
| 13:10 |
tsbere |
jeff: If you want to play with things something like this may be what we generally need: http://nsis.sourceforge.net/ShellExecAsUser_plug-in |
| 13:12 |
tsbere |
jeff: Or maybe this trick actually works too: http://mdb-blog.blogspot.com/2013/01/nsis-lunch-program-as-user-from-uac.html (with the benefit of not needing a plugin) |
| 13:20 |
|
akilsdonk joined #evergreen |
| 13:39 |
jboyer-isl |
jeff: I've seen software from some RFID vendors that tries to be smart about where it sends its data. You had to enter a list of window titles that can accept input. (Notepad would obviously be in the default set because of installer testing) |
| 13:39 |
jboyer-isl |
Oh hey, tsbere already said that. I hope it helped 20 mins ago. D: |
| 13:39 |
jboyer-isl |
:D |
| 13:40 |
jeff |
heh |
| 13:40 |
Bmagic |
Can anyone verify that there is no way to force the hold targeter to include newly catalogged items in the hold_copy_map sooner than every 24 hour laps from prev_check_time ? |
| 13:41 |
kmlussier |
Bmagic: Check-in modifier to retarget holds? |
| 13:41 |
tsbere |
Bmagic: Retarget local holds or manual selection of "find another target" are ways to get it to happen |
| 13:41 |
tsbere |
Bmagic: Or retargeting less than 24 hours apart, for that matter... |
| 13:41 |
jeff |
in the 3M software wedge, you typically configure a window title for it to send data to. If that window title is not present, it asks again. This becomes a minor annoyance when staff open close the first evergreen client window and open a second, since the window number is in the title, and thus the pad software re-prompts for a target. |
| 13:42 |
Bmagic |
so if there are 20 holds on a bib, you would need to "find another target" 20 times? |
| 13:42 |
tsbere |
jeff: I have seen something similar to that before....though the one I saw had poorly documented wildcard options that could be included. |
| 13:42 |
tsbere |
Bmagic: Normally you "find another target" for the likely hold to match, then the item captures for it and the other holds cease to be an issue for that particular copy. |
| 13:43 |
Bmagic |
tsbere kmlussier: thanks! |
| 13:43 |
kmlussier |
Bmagic: I think our libraries typically get in the habit of checking in newly-cataloged items with the check-in modifier so that the newly cataloged items are always targeted. |
| 13:43 |
Bmagic |
kmlussier: forgive me, what is a check-in modifier? |
| 13:44 |
tsbere |
Bmagic: "Retarget Local Holds" basically does the "find another target" dance for holds placed for pickup at the library you are logged into, making manual runs only needed when there are no local holds remaining |
| 13:45 |
kmlussier |
Bmagic: On the bottom of the check-in screen, there is a button for check-in modifiers to do things like forgive fines. Retargeting local holds is one of the options. We tend to leave those on at cataloging workstations. |
| 13:46 |
* kmlussier |
doesn't there is any information on this in the community docs. :( |
| 13:47 |
jeff |
do those cataloging workstations have receipt printers for printing hold slips, or do you opt not to print and hope the copy doesn't get lost on the way to the circ checkin station with a receipt printer? |
| 13:47 |
jeff |
receipt/slip |
| 13:50 |
tsbere |
jeff: "Capture local holds as transits" would possibly help there. |
| 13:50 |
jeff |
tsbere: *nod* |
| 13:51 |
tsbere |
especially on the "don't send out notifications until the copy is actually at the hold shelf" front |
| 13:52 |
jeff |
we make heavy use of that here. |
| 13:54 |
kmlussier |
jeff: I'm not really sure since I'm about two steps removed from the actual libraries. I just know we tell libraries to get in the habit of using those modifiers for new items. |
| 13:57 |
|
ericar left #evergreen |
| 14:00 |
tsbere |
jeff: From what I know of MVLC, most of our catalogers leave the items as "In Process" when they hand them off to the circ staff. |
| 14:01 |
jeff |
and our libraries are a combination of that and "my copy templates force item status to available (sometimes inappropriately)" :-) |
| 14:01 |
Bmagic |
kmlussier: Does it only include that new item for holds within the branch where the workstation is registered. Or System? |
| 14:02 |
tsbere |
Bmagic: the modifier should be looking at "for pickup at this branch" |
| 14:02 |
Bmagic |
tsbere: thanks! |
| 14:02 |
tsbere |
Though I think people have expressed desire for it to be able to look further, I don't recall seeing any actual work on it |
| 14:02 |
|
jihpringle joined #evergreen |
| 14:13 |
|
Dyrcona joined #evergreen |
| 14:18 |
* mmorgan |
reads backscroll, wishes hold targeting could happen in the background rather than the foreground... |
| 14:23 |
tsbere |
mmorgan: The problem with that is coming back to get the results. Unless you want a "retarget holds" interface that you run everything through, only to check them in again later to see what matches? |
| 14:26 |
mmorgan |
I don't want to have to run anything through an interface. I just want to check them in and have the system already know there is a hold that copy can fill. |
| 14:26 |
|
vlewis joined #evergreen |
| 14:27 |
mmorgan |
Maybe pie in the sky ... |
| 14:29 |
|
chatley joined #evergreen |
| 14:29 |
tsbere |
mmorgan: That would possibly necessitate a "when a copy is created or moved look up all holds that could possibly target it and start retargeting them in the background, likely skipping any that have been retargeted since the copy's creation date" type process. Which would likely increase loads more than a little. |
| 14:30 |
tsbere |
mmorgan: Oh, and you would *still* need to wait at least a few minutes before checkin, to give that process time to accomplish something |
| 14:30 |
jeff |
i think it is an aspect that is worth spending time to improve. |
| 14:31 |
kmlussier |
Ooh, almost forgot! |
| 14:31 |
kmlussier |
mmorgan++ #First code contribution to Evergreen. :) |
| 14:32 |
mmorgan |
Thanks! |
| 14:34 |
jeff |
mmorgan++ # congrats! |
| 14:36 |
mmorgan |
jeff: Thanks! I was inspired by bug squashing day. |
| 14:36 |
mmorgan |
kmlussier++ |
| 14:38 |
mmorgan |
But the holds thing - when a copy is created, or moved, or saved, would you really need to retarget ALL the holds? You only have to fill one after all. |
| 14:41 |
jeff |
crazy idea: given a new/updated copy, spray its copy id into all unfulfilled holds' hold_copy_map and let normal hold permit checks weed out the unsuitable holds. |
| 14:42 |
jeff |
and normal background hold targeting would trim things up as well. |
| 14:42 |
tsbere |
jeff: I assume you mean "all possibly matching holds" as the permit checks don't actually check if the copy is actually suitable for the hold from a target POV ;) |
| 14:42 |
* jeff |
nods |
| 14:43 |
jeff |
parts would probably be the most annoying part there, no? :P |
| 14:43 |
tsbere |
jeff: Which is easy for a single hold type. The code would have to collect holds across mutliple types, which would be more complicated. |
| 14:43 |
tsbere |
jeff: Parts would be amongst the *easiest* |
| 14:44 |
tsbere |
jeff: "This copy has part maps. As such, we ignore all volume, title, metarecord, issuance, etc holds and only look for part holds for the mapped part and copy level holds....the latter of which *shouldn't exist* because we just made the copy" |
| 14:44 |
eeevil |
yeah, M holds, don't even go there ;) ... but, T, C/F/R, I, V, P, those are pretty easy |
| 14:44 |
jeff |
holds of type C/V/T should be reasonable -- i suspect without checking that copy holds might not even rely on an ahcm entry. |
| 14:44 |
jeff |
M is trickier due to format and language limits |
| 14:45 |
eeevil |
and that's 99% coverage with a "M holds are special" documented errata |
| 14:46 |
jeff |
sure would be nice to get M in there as well. you'd need to identify the metarecord corresponding with the copy, then... language and format checks on the copy's bib vs the language and format restrictions on the M hold... what else am I forgetting? |
| 14:47 |
jeff |
(other than "this starts to get expensive and there is the potential for hundreds of holds", etc) |
| 14:52 |
mmorgan |
Would this need to happen with all holds? or just the most likely few to be filled next based on frozen, age, top of queue, etc? As jeff mentioned, the targeter is always running to clean things up. |
| 14:54 |
jeff |
you could exclude suspended/frozen holds and perhaps optionally other things, but one issue with limiting this to "only X holds" is that you run into cases where that optimization leads to inconsistent behavior. |
| 14:55 |
jeff |
(i've no issue with excluding suspended/frozen holds in this case) |
| 14:56 |
jeff |
but if some proposed new feature is supposed to eliminate the need to retarget (with checkin modifier or manually) holds for newly cataloged copies, but when you're doing age hold protection and there are a lot of older holds elsewhere and therefore the new feature SOMETIMES doesn't "work"... |
| 14:57 |
jeff |
then people just go back to retargeting, and it's almost as if you've wasted that time creating the new feature. :-) |
| 14:57 |
jeff |
(none of this is to say that i might not change my opinion on that, of course.) |
| 14:57 |
tsbere |
If we aren't doing a full targeting a single "insert into action.hold_copy_map" run with the hold IDs and the copy ID would take care of 90% of it, which if you are loading all the hold IDs *anyway* to check what holds to look at... |
| 14:58 |
mmorgan |
jeff: gotcha |
| 15:00 |
|
tspindler1 left #evergreen |
| 15:00 |
|
tspindler1 joined #evergreen |
| 15:05 |
mmorgan |
The new items are the biggest problem, also items that change from a nonholdable to a holdable status. If this could take care of these situations, it would be huge. |
| 15:21 |
|
mmorgan1 joined #evergreen |
| 15:25 |
eeevil |
jeff: thinking more, in modern EG it wouldn't be too bad to find appropriate holds. we store (what can "compile" down to) a queryint value to that can be used to find matching bibs within the MR of the copy's bib |
| 15:33 |
|
RBecker joined #evergreen |
| 15:39 |
jeff |
queryint looks like a new term to me. |
| 15:39 |
jeff |
holdable_formats is about all you'd need to pay attention to with hold_type = M, right? |
| 15:39 |
jeff |
at--eng and such? |
| 15:40 |
jeff |
that followed by --eng, i--eng, at-d-eng, and iat--eng seem to be our top holdable_formats values. :-) |
| 15:57 |
|
berick joined #evergreen |
| 16:02 |
Bmagic |
Before I posed my question, I was fillilng out a feature request on launchpad.... |
| 16:28 |
csharp |
hmm - the built-in patron merge is taking us 17+ seconds per record to process... any way to speed that up? we've only processed accounts that have a "Patron" profile, so we thought about commenting out some of the merge function |
| 16:28 |
csharp |
but I'm afraid that will leave traces of former staff |
| 16:29 |
csharp |
plus, it looks like the core stuff like money, circs and holds are why it's taking so long |
| 16:29 |
csharp |
anyone done a batch patron merge lately? |
| 16:31 |
dbs |
acid baths might be necessary for the last traces of those former staff |
| 16:32 |
dbs |
(note to self: do not accept a job at PINES) |
| 16:32 |
csharp |
haha |
| 16:32 |
csharp |
dbs: we'd love to have you :-D |
| 16:32 |
jeff |
just remember... HDPE. |
| 16:34 |
|
mmorgan1 joined #evergreen |
| 16:37 |
dbs |
csharp: aww you're sweet :) |
| 16:38 |
|
tspindler left #evergreen |
| 16:39 |
jeff |
(actually, LDPE) |
| 16:56 |
|
kmlussier left #evergreen |
| 16:59 |
|
remingtron__ joined #evergreen |
| 17:00 |
* dbs |
can't remember if those are the good cholesterols or the bad ones. Heh. |
| 17:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:18 |
eeevil |
jeff: sorry, query_int (for better googling). It may only be in 2.7? holdable_formats got ... more complex :) with MR holds coming back (via "the icon project") |
| 17:28 |
eeevil |
jeff: nope ... in 2.6. see: Open-ILS/src/sql/Pg/upgrade/0865.schema.convert-MR-holdable_formats.sql and Open-ILS/src/sql/Pg/upgrade/0864.MVF_CRA-upgrade.sql (the thing that can "compile" that) |
| 17:28 |
* eeevil |
runs away |
| 17:29 |
|
mmorgan left #evergreen |
| 17:36 |
Bmagic |
If I move a call_number to point to another record using a sql query, I notice that the destination record in the OPAC does not have the correct number of copies. The list of copies is correct but the number in the bulletted list is wrong "2 copies at Missouri Evergreen. " Should be 3 and there is clearly three in the list |
| 18:23 |
|
mnsri joined #evergreen |
| 18:29 |
|
wsmoak joined #evergreen |
| 18:29 |
|
wsmoak joined #evergreen |
| 18:37 |
|
buzzy joined #evergreen |
| 18:49 |
|
wsmoak joined #evergreen |
| 19:09 |
|
hbrennan joined #evergreen |
| 19:35 |
|
dcook joined #evergreen |
| 20:14 |
|
buzzy joined #evergreen |
| 20:34 |
jeff |
eeevil++ thanks! |
| 20:35 |
jeff |
Bmagic: my first thought is that the opac visibility cache wasn't updated for whatever reason, but that's maintained by a trigger... |
| 20:35 |
jeff |
Bmagic: what did your sql query look like? |
| 21:02 |
|
RBecker joined #evergreen |
| 21:04 |
|
Terence joined #evergreen |
| 21:56 |
Bmagic |
jeff: update asset.call_number set record=x where id=y; |
| 22:04 |
jeff |
this might tickle the opac visibility cache -- update asset.copy set id = id where callnumber = y; |
| 22:05 |
jeff |
i think there might also be a function to rebuild the opac visibility cache, but that might be overkill for this case. |
| 22:05 |
* jeff |
looks to see if there are triggers on acn that should have updated the visibility cache in the case of Bmagic's original update query |
| 22:07 |
Bmagic |
Jeff: I tried this with no luck: select asset.refresh_opac_visible_copies_mat_view(); |
| 22:10 |
jeff |
is the call number deleted? |
| 22:10 |
jeff |
do you have a link to the public opac record details page? |
| 22:11 |
Bmagic |
update asset.call_number set id=id where id=705863 no luck, update biblio.record_entry set id=id where id=3126 no luck |
| 22:11 |
Bmagic |
sure |
| 22:12 |
Bmagic |
http://mig3.missourievergreen.org/eg/opac/record/3126?expand=marchtml;copy_depth=0 (wait a minute, is the number referring to available only?) |
| 22:12 |
Bmagic |
jeff: LOL, sorry to bug you |
| 22:13 |
jeff |
that page looks correct. :-) |
| 22:13 |
Bmagic |
jeff: back to the duck on the keyboard again |
| 22:13 |
jeff |
*quack!* |
| 22:13 |
Bmagic |
jeff++ |
| 22:46 |
|
ldwhalen joined #evergreen |
| 23:08 |
|
tsbere joined #evergreen |
| 23:49 |
|
don joined #evergreen |
| 23:50 |
Guest6556 |
Hi~ :) I just want to ask in my evergreen 2.5.4 ubuntu 12.04 distro. I want to inrease my borrowed books the default is 10... but even I change it still 10 |
| 23:52 |
bshum |
Guest6556: Hi there, a quick question, when you say that the default is 10, is that a group penalty threshold for items checked out? |
| 23:52 |
Guest6556 |
yea |
| 23:52 |
bshum |
If so, raising that number does not retroactively remove the penalty from the patrons who exceeded it before it was raised. |
| 23:53 |
bshum |
Since they would have exceeded the penalty prior to the change. |
| 23:53 |
bshum |
What you can do is to remove the penalty from the users who are blocked. You should be able to see it in the "Messages" tab of the patron record. |
| 23:53 |
bshum |
Alternatively I'm not sure if hitting "Refresh" will recalculate the penalities |
| 23:54 |
bshum |
I don't think it does. |
| 23:54 |
bshum |
But I can't quite remember at this hour :\ |
| 23:55 |
bshum |
Removing the penalty will definitely work though, I think. |
| 23:56 |
Guest6556 |
I have number of client who reached the penalties now. I want to change the number so they can borrowed more books. but still it gives me 10. even I enter 15... |
| 23:57 |
bshum |
Right, if it was previously 10, those penalties are going to remain on those patron records until removed. |
| 23:57 |
bshum |
Because the policy was 10 at one point. |
| 23:57 |
bshum |
Updating it the policy to 15 does not automatically recalculate the penalties for users |
| 23:58 |
bshum |
You have to remove the old penalty off the patron's records. |
| 23:59 |
Guest6556 |
o.O oh my......well I will try now. I hope it worked.. |
