| Time |
Nick |
Message |
| 06:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:27 |
|
bdljohn joined #evergreen |
| 08:08 |
|
rlefaive joined #evergreen |
| 08:12 |
|
rlefaive joined #evergreen |
| 08:23 |
|
lsach joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:46 |
|
dbwells joined #evergreen |
| 09:01 |
|
yboston joined #evergreen |
| 09:15 |
|
kmlussier joined #evergreen |
| 09:36 |
|
jvwoolf joined #evergreen |
| 09:50 |
|
stephengwills joined #evergreen |
| 10:04 |
|
mmorgan1 joined #evergreen |
| 11:17 |
|
Christineb joined #evergreen |
| 11:22 |
|
khuckins joined #evergreen |
| 11:31 |
|
mmorgan joined #evergreen |
| 11:50 |
|
rlefaive joined #evergreen |
| 11:54 |
|
idjit joined #evergreen |
| 12:18 |
|
jihpringle joined #evergreen |
| 12:39 |
|
rlefaive joined #evergreen |
| 12:42 |
|
rlefaive joined #evergreen |
| 12:57 |
|
bdljohn1 joined #evergreen |
| 13:22 |
kmlussier |
@quote random |
| 13:22 |
pinesol |
kmlussier: Quote #88: "< eeevil> Now I am become Death, the destroyer of SIP2." (added by csharp at 04:45 PM, August 13, 2014) |
| 13:23 |
miker |
evergreen (ha! see what I did there?!) quote, if I do say so myself |
| 13:25 |
|
bdljohn joined #evergreen |
| 13:40 |
csharp |
miker++ |
| 14:11 |
* berick |
wonders if hold-transits should get canceled in open-ils.circ.hold.cancel now that we have that capability |
| 14:12 |
* mmorgan |
's ears perk up |
| 14:13 |
mmorgan |
hold-transits don't get cancelled now? |
| 14:15 |
berick |
interestingly, if the hold is "reset" its transit is canceled |
| 14:15 |
berick |
if the hold is canceled, the transit is not canceled |
| 14:15 |
berick |
that probably answers my question... |
| 14:16 |
mmorgan |
So this sounds like it would take care of canceling transits when patrons cancel their own holds. |
| 14:17 |
berick |
mmorgan: yeah |
| 14:17 |
berick |
well, patrons or staff |
| 14:18 |
mmorgan |
In xul, staff get asked if they want to cancel the transit after canceling the hold. Not sure about the web client. |
| 14:18 |
berick |
oh, huh |
| 14:19 |
berick |
i was just reading the code, maybe it's something we've solved in practice |
| 14:23 |
csharp |
I don't think it cancels the transit |
| 14:23 |
berick |
confirmed in master. canceling a hold updates the transit, so the copy will go back to reshelving, but leaves the hold uncanceled |
| 14:27 |
mmorgan |
berick: Do you mean "cancelling the transit"? |
| 14:27 |
berick |
sorry, yes, I meant it leaves the transit un-canceled |
| 14:27 |
berick |
(the hold does get canceled) |
| 14:28 |
* mmorgan |
runs away for a bit. |
| 14:50 |
* miker |
doesn't understand why a (non-lost) transit should be canceled ... that's what the copy is currently doing, and we should retain that knowledge, no? |
| 14:51 |
miker |
in the reset case, it kinda makes sense if you assume the reset is because the copy was scanned, captured, put in transit, and /then/ staff notice it's all busted up |
| 14:53 |
|
collum joined #evergreen |
| 14:54 |
berick |
miker: yeah, i know what you mean, and I suspect that's why it is the way it is. my thinking was now that we can cancel instead of deleting, we retain the info, in a way where no additional steps are required to clear the transit. |
| 14:56 |
miker |
you still have to scan it when it physically arrives, though. I mean, I assume. I wouldn't imagine there's a printed list of barcodes that staff filter for when a tub of books shows up |
| 14:58 |
berick |
miker: definitely, this is an edge case, still unpacking, but I think maybe the copy ends up somewhere else for whatever reason, and it really wants to keep doing to the pickup lib, even though it's no longer needed there. |
| 14:59 |
berick |
mostly, I wanted to confirm my understanding, and I can understand wanting to keep the transit alive |
| 15:01 |
|
khuckins joined #evergreen |
| 15:01 |
berick |
I found some local custimazations that delete such transits at checkin time, presumably so staff won't have to. I smells a possible YAOUS drifting in the breeze |
| 15:02 |
berick |
(to cancel, though, not delete) |
| 15:13 |
berick |
miker: recall why we never used prev_hop for transits went to the wrong branch? |
| 15:14 |
miker |
berick: just never happened, I think. the /orig/ orig idea was to be able to model multi-hop "routing", IIRC |
| 15:15 |
miker |
so not necessarily for wrong branch, but for PINES-like sorting centers, where the route may be dynamically identified on demand |
| 15:15 |
berick |
as in, the destination may change while it's en route? |
| 15:16 |
miker |
where each hop knows what it connects to, but not a full path. but, since that is unlikely to happen, I think "wrong branch" or "wasn't needed at that branch, going elsewhere, here's what just happened" would be a good use for that |
| 15:16 |
berick |
ok, cool, i'll open an LP. yeah, it's an easy bit of additional useful data |
| 15:26 |
* mmorgan |
returns and catches up. |
| 15:27 |
miker |
berick++ |
| 15:29 |
mmorgan |
Just want to mention with our delivery system, if a transit got canceled before an item reached the sorting site, it would be sent home rather than making it to the original destination. |
| 15:34 |
berick |
mmorgan: in that scenario, what's the preferred outcome, that it go home or keep going? |
| 15:35 |
mmorgan |
Go home:) |
| 15:35 |
berick |
mmorgan: ok, good to know, so there's def. a use case for such a setting |
| 15:35 |
mmorgan |
No point in it going somewhere else just to go back in delivery. |
| 15:35 |
|
khuckins_ joined #evergreen |
| 15:36 |
berick |
mmorgan: i assumed, but good to confirm |
| 15:40 |
berick |
a much better use case than what I was thinking about, in fact |
| 15:42 |
miker |
fwiw, I'm imagining "not needed /here/ because we force-filled a hold with another copy" and it gets captured at the dest for another (remote) hold |
| 15:44 |
berick |
yeah if it's returned home, there will certainly be cases where it goes right back out again, but there will presumably be many times where it doesn't. |
| 15:45 |
berick |
overall reducing deliveries |
| 15:46 |
miker |
well, you can already make that happen |
| 15:46 |
mmorgan |
In our case, holds go home, so if there's a hold at home and the item continues to its destination, it will turn right around and go home anyway. |
| 16:10 |
mmorgan |
Another frustration we sometimes see about transits. If a remote hold has been canceled, and the transit has not been, the owning library with the item in hand can't just check it in to clear the transit, even if there's reason for the item to be going anywhere else. |
| 16:11 |
mmorgan |
The transit needs to be canceled before the owning library can check it in. If they're unaware of the canceled hold, they may end up sending it in delivery just to have the transit clear on the other end so it can come home again. |
| 16:11 |
berick |
yeah, that's the scenario I was picturing. |
| 16:14 |
mmorgan |
berick++ |
| 16:15 |
jeff |
hrm. hold placed sunday has a current copy at a library that is closed sundays and mondays. not sure if this is unusual or not. |
| 16:18 |
mmorgan |
jeff: ou settings? circ.holds.target_when_closed, circ.holds.target_when_closed_if_at_pickup_lib ? |
| 16:18 |
jeff |
nope, second thing i checked! first was hours of operation. |
| 16:19 |
berick |
jeff: certainly not supposed to happen |
| 16:19 |
mmorgan |
Is the hold captured? |
| 16:20 |
jeff |
nope. |
| 16:20 |
|
yboston joined #evergreen |
| 16:20 |
mmorgan |
Do I remember that hours of operation is not consulted, only days closed is consulted? |
| 16:22 |
berick |
jeff: what's the retarget interval? |
| 16:23 |
berick |
mmorgan: confirmed hours of op. are not consulted, only close days |
| 16:23 |
jeff |
ah. |
| 16:23 |
jeff |
that would do it, then. |
| 16:24 |
jeff |
library is routinely closed on the weekdays in question, it isn't a "holiday" style closure. |
| 16:24 |
jeff |
so my expectations were out of sync, it seems. |
| 16:25 |
mmorgan |
lp 1665400 |
| 16:25 |
pinesol |
Launchpad bug 1665400 in Evergreen "Hold Targeter - Respect weekly schedule as well as closed holidays." [Undecided,Confirmed] https://launchpad.net/bugs/1665400 |
| 16:25 |
jeff |
berick++ mmorgan++ |
| 16:34 |
|
jvwoolf left #evergreen |
| 16:34 |
kmlussier |
berick: Can I remove you from the assigned column for bug 1514085? |
| 16:34 |
pinesol |
Launchpad bug 1514085 in Evergreen "Feature Request: Make Vandelay Asynchronous/Stateless" [Wishlist,Confirmed] https://launchpad.net/bugs/1514085 - Assigned to Bill Erickson (berick) |
| 16:35 |
berick |
kmlussier: yes, thank you |
| 16:35 |
* berick |
needs to practice his preachings |
| 16:37 |
kmlussier |
berick: We all do. |
| 16:38 |
kmlussier |
berick: In the current implementation, then, Vandelay is still in Dojo? |
| 16:38 |
berick |
kmlussier: yes, that branch only fixes the status updates / data streaming issues. |
| 16:38 |
berick |
Then ang6 code is in a different branch |
| 16:39 |
kmlussier |
berick: OK, thanks! |
| 16:39 |
berick |
i'll add the ang6 support for the new tracker table once it's merged to master |
| 16:57 |
jihpringle |
can someone tell me at what point of a release cycle newly translated strings stop being included? ie, do translations need to be submitted prior to Beta or can we submit them right up to the .0 release? |
| 17:03 |
berick |
jihpringle: we have string slush and freeze dates. the end of this week is the current slush date, where (IIUC) strings that need translating should existing where translators can get to them |
| 17:03 |
berick |
the string freeze, where we stop accepting new values is at the RC release, currently sept 19 |
| 17:04 |
berick |
so if you're talking about untranslated strings already in LP, you have a few weeks |
| 17:05 |
|
mmorgan left #evergreen |
| 17:17 |
|
rlefaive joined #evergreen |
| 17:26 |
|
khuckins joined #evergreen |
| 17:29 |
jihpringle |
thanks berick, we're at the stage of adding the translations for existing strings so good to know we have a few weeks |
| 17:34 |
|
rlefaive joined #evergreen |
| 17:34 |
berick |
jihpringle: have you have seen any of the discussion around translating the angular6 stuff? there was one note about it buried in my email from today. |
| 17:34 |
berick |
could use some feedback from translators |
| 17:37 |
|
rlefaive joined #evergreen |
| 17:59 |
Bmagic |
I can't figure out why my OPAC search results are not showing the search highlighting. It's upgraded production data on a dev machine. Using default OPAC tt2 templates. Is there a global flag? or library setting. I see that there is a line in config.tt2 but it's commented out |
| 18:10 |
dbwells |
Bmagic: The only global flag I know of is the "no highlight" flag which I assume you are saying is the commented out one. Maybe a dumb question, but is the "highlight" search modifier on in the OPAC iterface? |
| 18:15 |
dbwells |
Well, I guess that is a "disable" box as well, so probably not it. |
| 18:38 |
jihpringle |
berick: I saw the bit about translations in your email. At this point we're just looking at the patron facing translations (TPAC and self check) so I don't think applies to us yet |
| 18:38 |
Bmagic |
dbwells: I do see the checkbox on the OPAC "disable highlighting" and it's unchecked |
| 18:39 |
berick |
jihpringle: gotcha, thanks |
| 19:25 |
|
bdljohn joined #evergreen |
| 19:25 |
|
ningalls joined #evergreen |
