Evergreen ILS Website

Search in #evergreen

Channels | #evergreen index




Results

Result pages: 1

Results for 2026-04-28

17:16 eby stop using opac.hold_notify
17:16 eby and was general consensus in the room that per hold notify makes no sense and causes more issues
17:17 eby with updating the hold settings on patron change, etc
17:17 jeff also, I've had conversations here and elsewhere regarding removing some/all per-hold notification options. found some with this search: http://irc.evergreen-ils.org/evergr​een/search/?nick=jeff&q=carrier
17:17 Dyrcona Well. per hold notify makes a certain sense, but I'll agree it causes enough confusion to outweigh its usefulness.
17:17 jeff stop using opac.hold_notify? hrm.
17:19 eby well i think they were going for more clear not just hold related but when there was discussion there were multiple that wanted hold / overdue / courtesy broken out
17:20 eby so the slides are more let's just make hold_notify broken out into global sms / email / etc for all notices but the discussion went the other way
17:21 Dyrcona Do I understand correctly: 1 place (each) for email or sms values, then a setting for each notification to say which one to use?
17:21 jeff i support keeping per-hold exceptions in some ways/cases, mostly as exceptions and with some UI guardrails.
17:22 jeff thanks for the slides link. good place for me to start!
17:23 Dyrcona jeff: I think we'd have to keep that as an exception. It's hard to take a "feature" away that people might actually use (even if rarely).
17:24 Dyrcona left #evergreen
17:24 Dyrcona joined #evergreen
17:26 Dyrcona There is a use case for "I want to get notified differently for this hold or these holds." It should be an exception rather than the rule.
17:29 eby Dyrcona: yeah i think you have it right. The initial proposal from the work biblio is doing with sms was move to a global Notifications: [] email [] sms [] etc. vs the 'hold' label. They ran out of time but I also think simplifying what all needs updating when a patron replies STOP / automating  may have been a concern to be compliant
17:29 eby but quite a few in the room were wanting holds: x y z, overdue: x y z, courtesy: x y z
17:30 * jeff makes note to also review matches for this search: http://irc.evergreen-ils.org/evergre​en/search/?nick=jeff&q=per-hold
17:31 Dyrcona eby: I can see someone wanting to get sms for holds and email for overdue and/or courtesy notices.
17:31 eby that's our number one request
17:31 Dyrcona Our SMS vendor handles the STOP messages, so we don't worry about it in Evergreen, but I can see that becoming a concern for the ILS.

Results for 2024-07-11

15:12 pinesol News from commits: Docs: adding 3.13 to site.yml <https://git.evergreen-ils.org/?p=E​vergreen.git;a=commitdiff;h=3a58d1​c6ea1e89bb5914d768f36200a6195d7c2a>
15:20 cbrown-isl joined #evergreen
16:22 mmorgan For those that are using a true sms solution for text message, how have you dealt with hiding/removing the sms carrier option from the client and opac?
16:26 jeff less of an issue for us since we also hide per-hold notification methods, and we use our own patron-facing discovery layer and app.
16:26 jeff (and we don't rely on A/T for the automated text or phone call hold notifications -- just email)
16:28 jeff since this means our org unit setting for sms.enable isn't set to TRUE, we don't have to go out of our way to hide anything, just go out of our way to show a few things.
16:28 jeff like the "sms" notification pref in the user editor.
16:29 jeff we'd do it slightly differently now, I suspect.
16:30 jeff I think Stompro's branch hides the carrier while still using A/T and the sms.enable org unit setting.
16:31 rlefaive joined #evergreen
16:33 mmorgan I've just started looking at Josh's branch, we are still using action triggers.
16:49 jeff mmorgan: what provider are you experimenting with? Twilio, Flowroute, or something else?

Results for 2024-05-02

10:35 jvwoolf joined #evergreen
11:25 csharp_ berick: https://github.com/awesomized/libmemcached - this is apparently a resurrected version of libmemcached, so maybe RHEL isn't as dead as I thought for OpenSRF/Evergreen
11:25 csharp_ (following up on Monday's discussion)
11:31 jeff musing once again about making "hold notification options per hold" the exception, if not eliminating the feature entirely.
11:35 csharp_ jeff: sounds reasaonable from my vantage point
11:38 jeff we moved to "patron notification preferences at time hold becomes available" for all holds about nine years agors ago.
11:38 jeff funky keyboard ld lag creates interesting typos.

Results for 2023-09-05

15:47 Dyrcona So far, I've got two that failed the hooks lookup to create the AutorenewNotify events. I'm running the daily events along with the 2-day courtesy notices because they often overlap.
15:49 Dyrcona I think I'll set it up tomorrow so that 1 vm is configured with parallel reactors/collectors and the other not. Then, I'll put the production crontab in place to run these events and see what happens for a few days.
16:00 Dyrcona Unrelated: I'm starting to rethink many things that I thought were a good idea at the time, like letting users specify per hold email and SMS notification addresses. We get a few tickets now and then from staff who don't understand how they get bounce emails for addresses not in the patron record.
16:03 jeff per-hold email addresses aren't a thing that I'm aware of.
16:04 jeff email notification on holds is a boolean per-hold, but not a text field.
16:04 jeff you can have a different phone number per hold and a different text number (AND different carrier) per hold, though.
16:05 jeff (we do none of that)
16:09 Dyrcona The ticket is about the bounce from a text. We recently added real addresses as the senders of texts through email to SMS gateway, because it seems to help.
16:10 Dyrcona And, jeff, you're right. I should have looked it up before spouting off in channel, but different numbers seemed like a good idea once. Now, I think the cons outweigh the pros.
16:58 smayo joined #evergreen

Results for 2022-06-01

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

Results for 2019-05-22

12:12 sandbergja joined #evergreen
12:13 mmorgan joined #evergreen
12:32 Dyrcona jeff: Do I remember correctly that you use Twilio for SMS messaging?
12:34 jeff we do.
12:35 jeff We've also taken steps to make hold notification preferences per-patron and not per-hold-per-patron.
12:35 jeff (rather, not per-hold)
12:39 Dyrcona jeff: Thanks.
12:39 Dyrcona I'm starting to think the use case for per-hold notification preferences is wearing thin. :)
12:40 Dyrcona Sometimes too many options is a bad thing. :)

Results for 2017-09-27

16:42 jeff hrm. did we lose the ability to track when a user password had changed with the move to actor.passwd? seems so, but I might be missing something.
16:42 Dyrcona I would not mind seeing that changed so that the current phone# is used, but I'm sure someone had a reason.
16:42 mmorgan It also dawned on me at one point that patrons can't see their per hold notification choiceswhen viewing their holds. Maybe exposing that to the patron would help.
16:42 jeff Bmagic: yeah, we moved away from per-hold phone notification settings.
16:43 Bmagic jeff: how did you solve it?
16:43 Bmagic mmorgan: that would be an improvement for sure! Adding some details in the patron OPAC on the holds grid view
16:44 Bmagic grid is the wrong word, table
16:46 Dyrcona Yes, I would think so.
16:46 bshum YAOUS!
16:46 bshum (just felt like yelling that, for all the obvious and not so obvious reasons)
16:46 jeff not something we addressed. every time i proposed eliminating per-hold settings here there wasn't much interest, so we didn't pursue it.
16:49 kmlussier I think there has always been interest when it's raised here, but not always agreement on the solution.
16:50 Dyrcona Well, YAOUS, as bshum suggested.
16:50 bshum YAOUS!!
16:52 kmlussier Even with the YAOUS (or without), I think people who decide to use per-hold notifications would like the feature described here - https://bugs.launchpad.net/eve​rgreen/+bug/1570072/comments/1
16:53 pinesol_green Launchpad bug 1570072 in Evergreen "Hold request update notification preferences on change" [Wishlist,Triaged]
16:53 kmlussier But I suppose all these comments should go on the bug.
16:57 jeff do you think there's concensus now that we could eliminate per-hold phone numbers, per-hold text numbers, and per-hold text providers?
17:02 Bmagic jeff: I like having the possibility of the two being disconnected
17:02 jeff Bmagic: why?
17:02 Bmagic it makes perfect sense that each hold could be different. I see that as a nice feature. But, it's not clear to the staff or the patrons
17:15 miker I'm not saying I'd argue for the same designs today ... but it's not as slap-dash as it might seem in the modern world ;)
17:16 kmlussier Yes, and I'm not necessarily arguing that we keep it either. I honestly want to hear from people at the circ desk how they see people using it.
17:16 miker kmlussier: right, that's a more realistic version of my vacation scenario ... especially the fiction of me taking a 2-week vacation ;)
17:16 jeff miker: arguably per-hold text carrier was something done out of convenience and didn't have a supporting background use case, but i could be wrong on that one. :-)
17:16 kmlussier miker: I took a 2-week vacation back in 2002. It was splendid!
17:17 miker jeff: no, you're right about sms, I think
17:17 kmlussier jeff: We specifically asked that it be per-hold just as phone notifications were.

Results for 2017-03-09

15:10 csharp it's more for us, but I'mma have a similar approach
15:11 Dyrcona It should be removed from the default list, IMO.
15:11 csharp yeah
15:23 jeff for those using email to sms gateways, how much volume do you see in a given day/week?
15:24 jeff and how much grouping of notifications do you do -- mostly one notification per hold, perhaps unless several hit within the interval where you run the notifications?
15:25 jeff (i.e., grouped by usr or sms number, but only if there are several that become available between A/T runs from cron)
15:27 jeff Dyrcona: zero errors or warnings emitted by yaz-marcdump on my marc_export of all records.
15:27 jeff marc_export -a -e UTF-8 > export-all.mrc
15:27 jeff followed by
15:28 jeff yaz-marcdump -n -p export-all.mrc  | grep -v '^<!-- Record .* -->$'
15:28 jeff which i could have probably simplified to:
15:28 jeff yaz-marcdump -n export-all.mrc
15:32 csharp jeff: I'll have to do some research to get volume - it's a good question to address and terran's and my session at the EG conf </shameless_plug>
15:33 Enjabain joined #evergreen
15:34 csharp jeff: we group by sms number for hold requests, running every half hour

Results for 2017-02-02

10:32 StomproJ joined #evergreen
10:42 jeff okay, success in using window functions (LEAD, in this case) to report on patron alert message changes.
10:45 berick jeff: is there a LP bug for the "hold notices using old emails, etc." stuff?
10:49 jeff berick: i'm drawing a blank. are you talking about my desire to eliminate per-hold notification targets like phone and sms notify?
10:50 berick jeff: yes, you deciphered my vagueness ;)
10:50 jeff no, no LP that I'm aware of.
10:50 berick k, not finding one either
10:50 berick thanks
10:50 jeff i'm not sure if "rip it out" has enough support.
10:52 jeff "prompt staff to auto-update outstanding holds" and "configurable option to not ask for (and ignore/override) per-hold targets" have both been tossed around as compromises.
10:53 jeff i think people also have stronger opinions on the per-hold booleans vs the per-hold notification targets. in our environment, we've done away with both.
10:54 jeff your notification settings at the time that the hold goes available are how you are notified for that hold.
10:54 jeff (with one or two theoretical corner cases that i've on my list to hunt down)
10:55 * berick tests the tpac, sees that it forces patrons to use the email on the account and provides no way to change the email value
10:56 berick that kind of renders the whole feature useless, doesn' it?
10:56 jeff berick: because there is no per-hold email string, just a bool for yes/no.
10:56 jeff but unlike email, there are per-hold phone_notify and sms_notify (and sms_carrier) settings.
10:57 jeff which function as both bool and target, iirc.
10:57 berick oh, right...
10:57 berick thanks for the reminders, jeff
10:57 jeff if there's a value in phone_notify, then you send phone notification to the value present in that field, and if there's a value in sms_notify and sms_carrier, you send notifications there.
10:58 jeff but email_notify is just a bool, which means "send email to the address in actor.usr.email"
10:58 berick right, ok
10:59 jeff all of phone_notify (text), email_notify (bool), sms_notify (text), and sms_carrier(int) are set at hold request time based on a combination of values from actor.usr and actor.usr_setting.
10:59 jeff and then staff can change them after that.
10:59 jeff i think in stock tpac there isn't a way to change some/all of those per-hold.
11:00 jeff in jspac i'm pretty sure there was (though jspac may have pre-dated sms notification options).
11:02 jeff shifting gears, now i have a report that can be used to see patron alert message changes in the last X days, which can be useful for all manner of things.
11:03 jeff "on X date, user Y at workstation Z changed alert_message from A to B"
11:03 * csharp just created a report for staff to see SMS notify hold-ready notices
11:03 Christineb joined #evergreen
11:05 csharp http://pastebin.com/wP1PKjNr - for anyone who wants to build a template like mine

Results for 2016-12-14

12:13 * jeff muses once more about prompting staff when updating a phone number to confirm or update other phone numbers on the account (such as default hold pickup phone number)
12:17 * Dyrcona recalls that staff sometimes think changing a phone number updates all of the patron's options, etc., including the number on outstanding holds.
12:20 * kmlussier likes the idea of such a prompt
12:22 jeff well, on the subject of "number on outstanding holds", i still like the idea of not having per-hold phone numbers, but there's still the issue of the opac.default_phone user setting and friends.
12:22 Dyrcona Most people like the idea of a prompt until they have to click a button a few thousand times.
12:22 jeff well, the idea of course would be to not show it if it wasn't needed... :-)
12:23 Dyrcona Well, that goes without saying.... :)
12:49 kmlussier Yeah, I don't know if some users find the per-hold option useful. Maybe they do, maybe the don't. It would be nice to find out if some people do have a reason for using different numbers for different holds.
12:51 * mmorgan wonders if it would be less confusing and equally functional if per hold options were all yes/no
12:51 mmorgan and picked up the current user preference for phone and sms.
12:52 jeff we've gone further and just said "one set of prefs for all holds"
12:52 jeff "pref in effect at time of hold becoming available on-shelf is what is used"
12:57 jeff stated another way, notification prefs are per-user, not per-hold.
12:58 mmorgan jeff: gotcha. I'm not sure I'd like to see per hold notification go away entirely in our situation.
12:59 jeff Do you use it, or know how patrons use it?
13:00 Dyrcona I could see maybe choosing TXT notification for something that is very important to you, and email or phone for less important things.

Results for 2016-09-28

13:49 Dyrcona :)
13:54 Dyrcona dbs: There are some concerto titles with accented characters (CONC4000036) being the barcode for one.
13:54 Dyrcona It's Italian. The current code handles titles OK.
13:57 jeff hrm. why did i think that behind_desk was not a per-hold attribute?
13:57 berick jeff: it is
13:57 berick oh
13:57 jeff (there is indeed an action.hold_request.behind_desk boolean not null default false)

Results for 2016-04-14

09:52 kmlussier For example, a minor who is checking out material on a sensitive topic and whose normal notification settings go to an email address accessible to their parents.
09:54 kmlussier Actually, that's a bad example since you can't change the email address for the hold. But you get the point.
09:54 StomproJ kmlussier, I know there are valid reasons, I'm just lazy and don't want to deal with bounced notices.
09:55 jeff Where did we end up on the subject of bounced notices?
09:55 jeff Oh.
09:55 jeff When a patron overrides notification and the voice/text "bounces"?
09:56 jeff Are both of you advocating that we add the ability to have a per-hold email address as well?
09:57 kmlussier jeff: No, I wasn't. I was just selecting a poor example to illustrate a point. Sorry to get things off track.
09:57 StomproJ Yes, since there currently is no validation on data entered there.  I need to work on 1098685
09:57 jeff kmlussier seems to be suggesting that new feature, and StomproJ's reference to "bounced notices" made me wonder.

Results for 2016-04-13

14:24 StomproJ jeff; Do you check for the Default Phone notification setting when sending out phone calls?  Can I see your A/T for your AstCalls?  I thought that it was set to pick the default number if that was entered, but just looked at it again and the exmaples just show grabbing the day_phone number.
14:26 StomproJ jeff; miker; We also use asterisk running on a VM without telephony hardware (Using flowroute SIP provider) and we haven't had any problems.  Being able to place 20 calls at once is nice.
14:28 Dyrcona There's that overloaded acronym again....
14:36 jeff StomproJ: we do it outside of A/T, but I can tell you that the logic we use is roughly: at time of hold becoming available for pickup, determine voice and text prefs from user settings (or default if no user settings), then we base voice number on the user setting opac.default_phone or the value of actor.usr.day_phone (ignoring any invalid-looking values in both)
14:37 tarac__ joined #evergreen
14:37 jeff StomproJ: for text_number we use the first valid-looking value in either the user setting opac.default_sms_notify or actor.usr.day_phone
14:37 jeff StomproJ: we ignore other actor.usr phone fields at present
14:37 mrpeters1 joined #evergreen
14:38 jeff this has a side effect of the staff-client-side hold per-hold notification settings being something we just ignore. we don't use per-hold, just per-user-at-time-of-hold-being-ready.
14:39 rashma_away joined #evergreen
14:39 jeff we place max one voice call per day per phone number per pickup library, but for texts we'll do up to two messages.
14:39 rhamby_ joined #evergreen
14:39 mnsri joined #evergreen
14:39 jeff after that we back off for the rest of the day, and if they still have not-previously-notified-for holds they'll get new notifications the next day.
14:41 jeff we also do a bit where you might get a text saying "EXAMPLE TITLE ONE is now ready for pickup at LIBRARY" followed by "Multiple items including EXAMPLE DVD SIX are ready for pickup at LIBRARYNAME"
14:41 StomproJ jeff, thanks.  Ahhhhh, that is the bit that I was missing.  The example hold pickup astCall event def should probably get the phone from target.0.phone_notify instead of the target.0.usr.day_phone...
14:42 jeff so in theory you might have seventeen items ready for pickup now -- you need to check your account or come get them if you want to know what's ready.
14:43 jeff One thing I'm trying to figure out lately is the best way to tell a patron "no, we can't send you any more texts until you reverse the STOP message that you issued on DATE"
16:21 jeff StomproJ: since you've opened bug 1570072, I'll ask the question I've asked others before: do you see patrons intentionally using one-off hold-specific notification settings, and do you have insight into why they do?
16:21 pinesol_green` Launchpad bug 1570072 in Evergreen "Hold request update notification preferences on change" [Undecided,New] https://launchpad.net/bugs/1570072
16:22 StomproJ jeff, no, I just assumed that others have since it is designed as it is.  I would be fine with doing away with the per hold notification.  I just assume that there are sites that need that functionality.  1570072 would get rid of one of the gotchas for us.
16:26 jeff Just did a quick check -- we've had no patrons voice concern / objection / negative feedback regarding us removing the option for per-hold notification options.
16:26 StomproJ Maybe it just sticks around because everyone assumes someone is making use of that.  I just see constant errors being made at the point of placing holds.
16:27 * jeff nods
16:27 brahmina jihpringle: this is the page where google describes what to do if you have the "this site might be hacked" message... https://support.google.com/w​ebsearch/answer/190597?hl=en

Results for 2016-01-29

16:40 RoganH kmlussier: that's been my impression as well
16:40 RoganH gotta run, sick staff at a branch so I have to help them close, have a good weekend all!
17:01 Stompro Saving notification preferences in the catalog doesn't update current holds, right?  I think that would be a good enhancement, unless it already happens.
17:02 jeff yeah, we've hacked that in place here.
17:02 jeff i've argued for it a few times, perhaps arguing with code might be a good place to start. :-)
17:02 jeff but i know lots of people have different opinions on how that "should work"
17:02 jeff and what should be possible.
17:04 jeff i tend to favor "notification settings are per patron, not per hold" -- with maybe the ability to override per hold, but that might take some convincing :-)
17:04 Stompro jeff, I would agree with you on that.  I'm just seeing way too many mistakes made.
17:05 jeff most common is: patron has a new phone number, staff does not manually review and set phone notification on existing outstanding holds.
17:05 Stompro If someone changes ISP's and gets a new email, I don't really get how they are currently supposed to update all their holds.

Results for 2015-06-15

14:36 Bmagic ha
14:36 Dyrcona My first thoughts any way.
14:36 Dyrcona And placing holds.
14:37 jeff heh
14:38 jeff so, i've received a handful of use cases around support for per-hold notification methods and notification destinations (for phone and sms -- email is single-destination). i'm interested in more, if anyone has more. i'll still solicit same from the list at some point.
14:42 afterl joined #evergreen
14:46 Dyrcona jeff: I don't think that I have any to add beyond what tsbere mentioned to you earlier.
14:49 jeff tsbere++ Dyrcona++ thanks!

Results for 2015-06-12

12:48 berick in your logs, do you see a line like the first line in my paste?  that's testing the Text print
12:52 Bmagic It's not showing the lines with the numbers for the print job. AKA n\n1234567890123456789012345678901234567890
12:55 berick no line that starts out 2015-06-12 12:42:35.453:INFO:WebSocke​tHandler:qtp2051450519-26: onMessage() {"action":"print",...
12:55 jeff If I were to advocate for removal of the per-hold customization of notifications, would anyone here strongly oppose that?
12:56 jeff i.e., moving "how to notify me for holds" away from the per-hold status quo to being a per-patron thing.
12:57 berick jeff: i would not (personall) object.  not sure about my overlords.
12:57 berick er, personally
12:59 Bmagic berick: http://pastie.org/10237599 might help answer
12:59 jeff currently, there are defaults set at the patron level, and those defaults are used when the hold is placed. patrons can diverge from the defaults at time of hold placement (and staff can edit notification options per hold after that).
12:59 jeff there is no way for a patron to change their default notification number and have that change affect outstanding holds, short of staff intervention.
13:00 berick Bmagic: ah, there's no conent...
13:00 berick nothing to print
13:00 berick that's interesting
13:00 jeff there is also no interface where patrons can even see what notification options are set per hold, etc.
13:01 berick Bmagic: chrome or FF ?
13:02 Bmagic berick: print with dialog shows a bit more output. Chrome
13:02 berick Bmagic: that could very well be an evergreen version problem
13:22 jeff and, i am looking at our own data here also -- not just relying on mmorgan :-)
13:25 mmorgan jeff: one usr picked at random shows non-contiguous notification choices. A sample of one is not very conclusive, though ;-)
13:26 * mmorgan needs to slip away for a bit. will look at more data later.
13:33 jeff sampling of eight users (who placed the most recent 20 holds) seems to indicate one who has occasionally enabled/disabled phone notifications.
13:36 jeff short of a harder-to-detect variation in the method being used to place those (accounting for possible differences in mobile app vs 'place hold on all items in this list', etc), i think we've confirmed the (already suspected likely) fact that >0 users make use of distinct per-hold notification options.
13:37 jboyer-isl I think per-hold true/false values would be great, I'm less happy with the per-hold values. We regularly get "Why are you notifying this patron at the "wrong" number/email?!", etc.
13:37 * jeff nods
13:37 jboyer-isl Bonus: those are easy to turn into editable options in the tpac, if we want to go all the way.
16:00 pinesol_green [evergreen|Michael Peters] LP#1154656 MARC Expert Search "Add Rows" adds duplicate row - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7903e32>
16:00 Dyrcona bug_squashing_day++
16:00 jboyer-isl jeff: totally unnecessary dev database. But one of the problems with allowing perl in-db is that sometimes postgres can't cancel things itself (such as when you're testing stupid regex tricks)
16:03 jeff here, we're probably moving away from per-hold notification options, toward user settings.
16:05 Dyrcona rashma++ #testing braches
16:06 Dyrcona branches, even. ;)
16:07 goood joined #evergreen

Results for 2014-09-24

15:29 jeff i can think of a few approaches...
15:30 kmlussier I don't recall an existing LP bug, but I have thoughts on that too.
15:30 kmlussier Mainly, a prompt that appears when updating a patron phone number asking if you should update the number on all existing holds.
15:31 jeff i'm also interested in moving away from per-hold notification options...
15:32 jeff or at least making the decision (by either patron or policy) to not have per-hold notification options easier.
15:32 cherri joined #evergreen
15:33 remingtron_ joined #evergreen
15:33 csharp remingtron_: welcome

Results for 2013-12-04

15:35 jeff from a user perspective, i think that there's room for improvement.
15:35 * csharp just got around to reading the "next gen" email :-/
15:36 csharp marketing_speak--
15:36 * jeff muses
15:37 sseng joined #evergreen
15:37 jeff currently, the default notification prefs are consulted at hold request time, and if your phone number or similar changes, each outstanding hold would need to be individually updated.
15:37 jeff likewise if someone decides they no longer wish to receive phone calls about holds.
15:38 jeff i suspect that even with patrons that vary their notification method per hold, it's an unusual thing.
15:39 misilot joined #evergreen
15:39 jeff so might be an improvement to have "notify me in the usual way" vs "notify in an unusual way" at hold placement time...
15:39 csharp "for these three holds, call me at *this* number - for these other four, email me at the following four separate email addresses"
15:40 jeff we don't offer different e-mail addresses, and i'm okay with sticking with that.
15:40 csharp "then leave a red flag in the flower pot at the rear of the library"

Results for 2013-09-05

09:37 rfrasur right
09:37 paxed aahh!
09:37 paxed thanks, that cleared it up
09:38 jeff the preference is set in the patron editor by staff, but i believe there is recent work in master and possibly 2.5 that allows it to be set on a per-hold basis. i don't know if that's by staff or patron or both.
09:38 collum It's both.   I'm looking for the link in LP.
09:38 jeff with the per-hold option, a flag indicating "this hold is behind the desk' is useful for things like inter-library loans and state resource sharing (another form of ILL, really), where the items cannot self-check and aren't on the public shelf.
09:39 * tsbere fixes git.evergreen-ils.org so that it can update working again as a distraction from his other issues
09:39 jeff tsbere++
09:39 jeff thanks.

Result pages: 1