| Time |
Nick |
Message |
| 06:59 |
|
annagoben joined #evergreen |
| 07:05 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
bdljohn joined #evergreen |
| 07:32 |
|
rmiller joined #evergreen |
| 07:36 |
rmiller |
Can anyone help me with an error in a fresh OpenSRF install on Ubuntu Bionic? It looks other people have had the same problem, but I can't find the solution: http://libmail.georgialibraries.org/pipermail/open-ils-general/2018-August/015294.html |
| 07:44 |
rmiller |
I forgot y'all moved time zones on me. I'll come back when you're awake :) |
| 08:07 |
|
plux joined #evergreen |
| 08:16 |
|
bdljohn joined #evergreen |
| 08:22 |
|
bos20k joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:44 |
bshum |
@later tell rmiller Ubuntu Bionic support is still in progress for OpenSRF/Evergreen. Your best option for Ubuntu is to use Xenial 16.04 |
| 08:44 |
pinesol |
bshum: The operation succeeded. |
| 08:55 |
|
jvwoolf joined #evergreen |
| 08:57 |
|
stephengwills joined #evergreen |
| 09:04 |
stephengwills |
I’ve upgraded db schema to 3.1 and srfsh allows me to log in but my search reveals no items. I tried reingesting and still no joy. suggestions? |
| 09:06 |
|
ningalls__ joined #evergreen |
| 09:12 |
pinesol |
[evergreen|Dan Wells] LP#1635737 Add optional context to interval_to_seconds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ac48931> |
| 09:12 |
pinesol |
[evergreen|Mike Rylander] LP#1635737: Unit tests for DST and date math - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a659357> |
| 09:12 |
pinesol |
[evergreen|Dan Wells] LP#1635737 Use new OpenSRF interval_to_seconds() context - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bd047ba> |
| 09:12 |
pinesol |
[evergreen|Mike Rylander] LP#1635737 Apply DST-aware timezone to context dates - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=319f82d> |
| 09:12 |
pinesol |
[evergreen|Bill Erickson] LP#1635737 Due date DST-aware thinko fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e067e00> |
| 09:22 |
|
yboston joined #evergreen |
| 09:27 |
berick |
dbwells: working/user/berick/lp1635737-syntax-fix |
| 09:29 |
|
abowling joined #evergreen |
| 09:32 |
pinesol |
[evergreen|Bill Erickson] LP#1635737 Due date DST noncat thinko fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c193f41> |
| 09:33 |
|
ningalls___ joined #evergreen |
| 09:34 |
|
mmorgan joined #evergreen |
| 09:38 |
stephengwills |
one thing I notice is my database as I’ve walked it up the upgrade steps is Collate UTF-8 and CType UTF-b and my production DB is C for these features. is that a useful clue or a red herring? |
| 09:38 |
stephengwills |
CType UTF-8 sorry, typo |
| 09:39 |
|
kmlussier joined #evergreen |
| 09:39 |
|
terran joined #evergreen |
| 09:39 |
|
tlittle joined #evergreen |
| 09:39 |
remingtron |
https://wiki.evergreen-ils.org/doku.php?id=scratchpad:webstaffcolumns |
| 09:39 |
remingtron |
(for terran and tlittle) |
| 09:40 |
|
abowling joined #evergreen |
| 09:40 |
|
ningalls__ joined #evergreen |
| 10:03 |
|
rmiller joined #evergreen |
| 10:08 |
|
mmorgan1 joined #evergreen |
| 10:09 |
|
JBoyer joined #evergreen |
| 10:14 |
ejk |
Small personal victory: I have updated a MARC record from PHP. \o/ |
| 10:17 |
jeff |
ejk++ |
| 10:19 |
ejk |
Thanks jeff++ and dbwells++ and all |
| 10:20 |
dbwells |
ejk: nice |
| 10:22 |
jeff |
laptop experienced "sleep failure", and all i can think of while all of my tabs re-open is castlevania 2: https://youtu.be/7tNQXwjAlI0 |
| 10:24 |
csharp |
ejk++ |
| 10:24 |
* csharp |
experiences a lot of sleep failure |
| 10:26 |
* mmorgan1 |
also finds that "sleep failure" often leads to "wake failure" |
| 10:28 |
JBoyer |
jeff++ |
| 10:29 |
* JBoyer |
also had a laptop scare, had to look up his Bitlocker Recovery Key. |
| 10:29 |
JBoyer |
Always fun to ask yourself what new laptops run these days |
| 10:43 |
|
khuckins joined #evergreen |
| 10:58 |
|
sandbergja joined #evergreen |
| 11:06 |
pinesol |
[evergreen|Dan Wells] LP#1724348 Honor default tab from catalog search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b11fba> |
| 11:06 |
Bmagic |
I can't seem to find the bug but I'm sure it's been reported: patron penalties get applied, then the group penalty definition is removed, but all of the penalties that were applied do not. |
| 11:08 |
Bmagic |
or* the patron permision group changes, and the group penalty should no long apply but since it used* to apply, it's not removed |
| 11:12 |
mmorgan |
Bmagic: bug 979922 ? |
| 11:12 |
pinesol |
Launchpad bug 979922 in Evergreen "Changing patron user groups does not force a recalculation of existing group-based circ limit penalties" [Undecided,Confirmed] https://launchpad.net/bugs/979922 |
| 11:14 |
Bmagic |
That's it! |
| 11:14 |
mmorgan |
That bug's a little dusty! |
| 11:17 |
Bmagic |
mmorgan++ |
| 11:18 |
Bmagic |
yeah, It seems like staff could open the patron account and click on "messages" then delete the penalty manually? |
| 11:21 |
Bmagic |
Another interesting thing that is perplexing me. This bib visibility issue again. I've got a bib that has a visibility set but it does have copies attached which I thought means it should not* have anything between the curly brackets but it does "{268435458}" |
| 11:21 |
mmorgan |
Bmagic: They could, but they shouldn't have to. And it doesn't help patrons logged into the catalog. |
| 11:22 |
* mmorgan |
thought there was some discussion at some point about recalculating system penalties, but can't locate it. |
| 11:22 |
Bmagic |
Another potential clue, is it has an integer set for merged_to.... a column I've never seen before |
| 11:25 |
Bmagic |
Looking at the biblio.record_entry row ID referenced in the merged_to, I see that it's probably the same bib, but that one doesn't have copies. It's vis_attr_vector is null. |
| 11:29 |
|
jihpringle joined #evergreen |
| 11:29 |
|
ningalls__ left #evergreen |
| 11:32 |
mmorgan |
Bmagic: merged_to came in with 3.1, bug 1744996 |
| 11:32 |
pinesol |
Launchpad bug 1744996 in Evergreen "Wishlist: Tracking bib record merges" [Wishlist,Fix released] https://launchpad.net/bugs/1744996 |
| 11:35 |
jeff |
Bmagic: in general a Refresh of the patron is enough to remove most (all?) relevant penalties that would have changed because of the group penalty threshold change or group membership change. |
| 11:36 |
Bmagic |
the issue with that is that there is no longer a penalty definition for the recalculator to compare to |
| 11:36 |
jeff |
Bmagic: ah, when it's removed i'll bet that does cause an issue (though possibly only for some penalties). |
| 11:37 |
Bmagic |
right, or "no longer applies" because the patron permissoin group changed |
| 11:41 |
* jeff |
nods |
| 11:42 |
jeff |
as opposed to "new group has a different value", it's "new group doesn't have a threshold defined at all"? |
| 11:53 |
gmcharlt |
miker: and now at 99% for the Perl side: https://pastebin.com/FtKdqL6j |
| 11:59 |
jeff |
it appears that a search filter group entry with a query of locations(116) ends up not restricting results to that location. observed on 3.1, also reproduced on webby a few minutes ago. I've found some similar bugs in LP but I'm not sure that I've found one that addresses this yet. Ring any bells with anyone here, or should I dig further? |
| 12:01 |
jeff |
other search filter group entries like the stock/concerto kpac examples based on audience() seem to work, and a locations(116) seems to work, just not via the filter_group_entry(n) abstraction |
| 12:03 |
Bmagic |
jeff: correct "not defined at all" |
| 12:07 |
jeff |
actually, now i'm not convinced that the locations(n) syntax is working as expected on webby, but filter_group_entry(n) with a locations(n) search appears to not be limiting to that location -- seems to return the same results as if there was no filter_group_entry(n) specified. |
| 12:07 |
gmcharlt |
miker: and see working/user/gmcharlt/lp1729610_request_queuing_mark2 |
| 12:08 |
gmcharlt |
(for OpenSRF) |
| 12:09 |
Bmagic |
morgan: merged_to column. I have an example that shows that each bib was merged onto eachother and neither one is deleted... |
| 12:12 |
pastebot |
"plux" at 64.57.241.14 pasted "hiiting keyword search failure post reingest 3.2.0 and 3.2.1 - anyone come across that before?" (5 lines) at http://paste.evergreen-ils.org/14296 |
| 12:16 |
jeff |
Bmagic: small data point, i have no examples of that (zero rows where merged_to is not null and deleted = false) |
| 12:16 |
Bmagic |
hmmmm, somehow this happened. I'll see if there are more examples |
| 12:17 |
jeff |
Bmagic: i wonder if merging rec1 to rec2 and then un-deleting rec1 and then merging rec2 to rec1 and then un-deleting rec2 would do it. seems pretty specific and convoluted, but might be possible. |
| 12:17 |
Bmagic |
ah, that could be |
| 12:17 |
* mmorgan |
was thinking of something similar to jeff's scenario |
| 12:17 |
Bmagic |
select count(*) from biblio.record_entry where not deleted and merged_to is not null; count = 2 |
| 12:17 |
jeff |
Bmagic: also, might be that there's a less convoluted set of circumstances that could lead to what you're seeing. |
| 12:18 |
Bmagic |
undeleted the bib should null out those two columns right? |
| 12:19 |
mmorgan |
Maybe staff user chose the wrong lead record for the merge, then tried to fix the error |
| 12:20 |
Bmagic |
in either case, the system should* null merged_to and merged_date when a bib is undeleted? |
| 12:20 |
Bmagic |
it seems to impact vis_attr_vector because it's nulled when merged and not recalculated when undeleted |
| 12:20 |
jeff |
Bmagic: there does not seem to be provision in the original feature (bug 1744996) for clearing merged_to or merge_date on record un-delete, no. |
| 12:20 |
pinesol |
Launchpad bug 1744996 in Evergreen "Wishlist: Tracking bib record merges" [Wishlist,Fix released] https://launchpad.net/bugs/1744996 |
| 12:23 |
Bmagic |
Do you agree that we have a bug here? (I didn't want to report it and look silly) |
| 12:23 |
* mmorgan |
would agree there's a bug |
| 12:24 |
jeff |
yes, I think there's at least one bug here. |
| 12:26 |
Bmagic |
incoming report then |
| 12:27 |
Bmagic |
I am still a bit perplexed by the value that I am seeing in vis_attr_vector. It's "{268435458}" - I thought this was a list of org_units, but that number is not an org unit |
| 12:27 |
jeff |
looks like merge_date should only be nulled on undelete if merged_to was not null before undelete. |
| 12:27 |
jeff |
heh. |
| 12:29 |
jeff |
that's a slightly more complicated answer, and requires delving into the "novel data structure" |
| 12:31 |
Bmagic |
hmmm, that is one number and not several numbers concatenated (grasping at straws)... I do notice that the same bib has a source id |
| 12:31 |
mmorgan |
Bmagic: I have a concerto test system that shows 2 biblio.record_entry rows with that value in vis_attr_vector |
| 12:32 |
Bmagic |
interesting, with that value, which search scopes will it result the bib? |
| 12:32 |
mmorgan |
and one record that has {268435457} |
| 12:33 |
jeff |
268435458 indicates "bib source 2" |
| 12:33 |
Bmagic |
weird, that seems redundant when the bib source is defined already on the same row |
| 12:36 |
Bmagic |
What is it about the bib source that has anything to do with search visibility (especially when transcendant is false) ? |
| 12:36 |
jeff |
in terms of bib vis attrs, luri_org is 0 and bib_source is 1. to calculate "bib_source of 2" it's: |
| 12:36 |
jeff |
select search.calculate_visibility_attribute(2, 'bib_source'); |
| 12:36 |
jeff |
or the underlying math: |
| 12:36 |
jeff |
select 1<<28 | 2; |
| 12:39 |
Bmagic |
This bib is not electronic, and it does have physical copies on it, which, i thought* , means it shouldn't have anything between the curly brackets |
| 12:41 |
jeff |
if a bre has a source and is not deleted, it should have at least one value in vis_attr_vector. |
| 12:41 |
jeff |
if it also has located URIs, it will have at least one additional value in vis_attr_vector. |
| 12:42 |
jeff |
since luri_org is bib attr zero, those look just like org unit ids. |
| 12:42 |
jeff |
so this returns "123": select search.calculate_visibility_attribute(123, 'luri_org'); |
| 12:43 |
jeff |
but this returns "268435458": select search.calculate_visibility_attribute(2, 'bib_source'); |
| 12:43 |
Bmagic |
The catalogers think that this bib should be showing up in search results but it's not. And i think it's due to the value in the vis_attr_vector |
| 12:45 |
jeff |
my understanding is that biblio.record_entry.vis_attr_vector is not going to result in a decision to NOT show a bib. it's only going to ever force a bib with no "visible" copies to be shown when the luri_org or bib_source brings it into scope. |
| 12:46 |
jeff |
(either because the luri_org is in scope for the search, or because the bib_source is defined as transcendant) |
| 12:46 |
jeff |
so i'd look at your copy visibility for the copies on that bib. |
| 12:47 |
Bmagic |
ok, let me see what that turns up |
| 12:48 |
jeff |
how many copies are on the bib? care to share output of SELECT * FROM asset.copy_vis_attr_cache WHERE record = [bib_id_here]? |
| 12:48 |
Bmagic |
All copies are visible in both asset.copy and asset.copy_location |
| 12:49 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "output for copy visibility" (12 lines) at http://paste.evergreen-ils.org/14297 |
| 12:51 |
|
yboston joined #evergreen |
| 12:54 |
|
collum joined #evergreen |
| 12:56 |
|
khuckins joined #evergreen |
| 12:58 |
jeff |
Bmagic: is that bre deleted in your db? |
| 12:58 |
Bmagic |
no, not deleted |
| 12:59 |
Bmagic |
also when undeleting, it seems like the biblio.calculate_bib_visibility_attribute_set should be run. Looking over the function biblio.indexing_ingest_or_delete(), I'm not seeing references to that |
| 13:08 |
jeff |
how about SELECT * FROM metabib.record_attr_vector_list WHERE source = 693452; |
| 13:08 |
jeff |
trying to think of places where we've had problems with deleted-then-undeleted records in the past. |
| 13:10 |
Bmagic |
yeah, I think yo uare on to something. These are not showing a format icon either..... |
| 13:12 |
jeff |
this messy query should rule out copy visibility issues: https://gist.github.com/jeff/338326337eed82f1a60cde1f388b2123 |
| 13:13 |
jeff |
(it's a bit overkill, but if there are any copy IDs output by that query then you can probably stop focusing on copy visibility issues) |
| 13:18 |
|
beanjammin joined #evergreen |
| 13:25 |
Bmagic |
I am trying to reproduce the undeleted bit. Did the undelete command get removed from Webby? |
| 13:25 |
mmorgan |
Bmagic: Just came across that this morning, it's on the marc edit screen. |
| 13:26 |
Bmagic |
ah! lol |
| 13:26 |
Bmagic |
mmorgan++ |
| 13:27 |
mmorgan |
Also noticed this morning that undelete in web client behaves differently than in xul, at least as far as located uris are concerned. |
| 13:28 |
mmorgan |
So visibility when undeleting in the web client could potentially behave differently, too |
| 13:29 |
jeff |
mmorgan: what did you observe with regard to differences with located uris in webby vs xul on bib undelete? |
| 13:30 |
* mmorgan |
is looking for lp bug |
| 13:34 |
jeff |
mmorgan++ |
| 13:36 |
mmorgan |
The bug is lp 1387725, but it's only peripherally related to jeff's question. |
| 13:36 |
pinesol |
Launchpad bug 1387725 in Evergreen "Bibliographic record merging for electronic resources should delete Located URIs" [Medium,New] https://launchpad.net/bugs/1387725 |
| 13:37 |
mmorgan |
To answer the question, we discovered that when undeleting a bib record in the web client with an 856 that had been previously deleted because of a merge, the uri was regenerated. |
| 13:38 |
mmorgan |
Doing the same undelete in the xul client did not result in generating a new uri. |
| 13:57 |
|
sandbergja joined #evergreen |
| 14:47 |
|
Dyrcona joined #evergreen |
| 14:48 |
* Dyrcona |
got bumped in DTW (Detroit) not leaving until 10:00 PM tonight. |
| 14:48 |
JBoyer |
D: |
| 14:49 |
* Dyrcona |
will also have questions about action_trigger_runner.pl because it is not working on my test vm, but it was a couple of weeks ago. (I know that's vague, but I have to start looking at it again.) |
| 14:49 |
|
kmlussier joined #evergreen |
| 14:58 |
csharp |
has anyone out there done a batch forgive of bills that I might crib from? starting from scratch is... not fun |
| 14:59 |
mmorgan |
csharp: I asked a similar question a week or two ago without response :-( |
| 15:00 |
csharp |
mmorgan: thanks |
| 15:00 |
csharp |
mine is a "do this by tomorrow" kind of thing |
| 15:00 |
csharp |
anyway, I'll keep plugging at it |
| 15:00 |
csharp |
wish I was more comfortable with cronscript/perl for this kind of thing :-/ |
| 15:01 |
* mmorgan |
was wondering if simply inserting a row into money.forgive_payment would get all the right wheels turning. |
| 15:03 |
mmorgan |
But that would be too easy. |
| 15:12 |
Dyrcona |
It probably would, but I think I'd find the appropriate payment creation call from open-ils.circ. |
| 15:13 |
Dyrcona |
I might have done something like this before. I'll take a look in my old files in a moment. |
| 15:14 |
* Dyrcona |
is doing something that should take a couple of minutes. |
| 15:16 |
jeff |
csharp: we've done mass-forgives. script is probably fragile, but better than starting from scratch... maybe. |
| 15:21 |
Dyrcona |
I've got something that I'll paste to my Evergreen pastebin after I add a license header. It should make a good example. |
| 15:24 |
Bmagic |
csharp: I just rant this on production last week https://github.com/mcoia/mobius_evergreen/blob/master/Random/forgive_migrated_overdues_example.pl |
| 15:25 |
Bmagic |
rant/ran |
| 15:32 |
Dyrcona |
chsarp | mmorgan: https://pastebin.com/feAsnERF I did that for MVLC when I worked there. I guessed on the copyright date. :) |
| 15:34 |
mmorgan |
csharp^^ |
| 15:34 |
Dyrcona |
Oops. Sorry. |
| 15:34 |
mmorgan |
Bmagic++ |
| 15:34 |
mmorgan |
Dyrcona++ |
| 15:42 |
|
plux left #evergreen |
| 15:42 |
Dyrcona |
So, I'm trying to figure out why action_trigger_runner.pl appears to do nothing on my test VM. It was working a week or so ago. |
| 15:42 |
Dyrcona |
It runs but says there's nothing to do, basically. |
| 15:42 |
Bmagic |
what are all of the arguments, granularity? |
| 15:43 |
Dyrcona |
Specifically, I'm trying to get the hold expires from shelf soon to run for a test. |
| 15:43 |
Dyrcona |
I have it set up with -2 days delay and a granularity of daily. |
| 15:43 |
Dyrcona |
I have other daily granularity events that ought to fire, too. |
| 15:43 |
mmorgan |
Dyrcona: Is the event definition enabled? |
| 15:44 |
Dyrcona |
It is. I have a relatively fresh copy of production data, i.e. from yesterday at midnight. |
| 15:44 |
Bmagic |
The logs usually have a json query used to lookup the candidates |
| 15:44 |
Dyrcona |
When I run "action_trigger_runner.pl --osrf-config /openils/conf/opensrf_core.xml --process-hooks --run-pending --granularity daily" it exits rather soon and nothing ends up in action_trigger.event. |
| 15:45 |
Bmagic |
the json query has ofen lead me to the reason |
| 15:45 |
Dyrcona |
I have checked the validator query and it should allow about 1,200. I'll check the logs again for the collector query. |
| 15:46 |
Bmagic |
perhaps the date on the VM is not in sync with the data in ahr ? |
| 15:46 |
Bmagic |
timezone settings are different per linux user sometimes |
| 15:47 |
Dyrcona |
The date on the VM is correct. |
| 15:47 |
Dyrcona |
I scheduled one to run with "at" when it normally runs in cron on production, in case that has something to do with it, but if that were the case, I'd expect to pick the ones for tomorrow already. |
| 15:48 |
|
ejk joined #evergreen |
| 15:48 |
|
eby joined #evergreen |
| 15:49 |
|
kipd joined #evergreen |
| 15:51 |
Dyrcona |
I don't find the hold_request.shelf_expires_soon hook mentioned in the osrfsys.log, but I do find checkout.due. The hook is passive, but that shouldn't matter, should it? |
| 15:52 |
csharp |
Dyrcona++ |
| 15:52 |
csharp |
Dyrcona++ |
| 15:52 |
csharp |
Dyrcona++ |
| 15:52 |
csharp |
that's extremely helpful |
| 15:52 |
|
stephengwills joined #evergreen |
| 15:53 |
Dyrcona |
Glad it is. |
| 15:53 |
csharp |
Bmagic++ |
| 15:53 |
csharp |
Bmagic++ |
| 15:53 |
csharp |
Bmagic++ |
| 15:53 |
csharp |
too :-) |
| 15:53 |
mmorgan |
Dyrcona: Does your action_trigger_filters.json file refer to "hold_request.shelf_expires_soon"? |
| 15:54 |
Dyrcona |
mmorgan: Y'know what. I may not have put the standard filter file in place. |
| 15:56 |
Bmagic |
mmorgan++ |
| 15:56 |
Dyrcona |
mmorgan++ # That was it. |
| 15:57 |
mmorgan |
Yay! |
| 15:57 |
Dyrcona |
It's doing something, now. |
| 15:58 |
mmorgan |
So many knobs for action triggers |
| 16:01 |
kmlussier |
mmorgan++ |
| 16:08 |
|
khuckins_ joined #evergreen |
| 16:15 |
mmorgan |
I've been looking at permissions and ou_settings. In the staff client, it seems like a user can either see all or none of the library settings. |
| 16:16 |
csharp |
mmorgan: each setting type has view and update perms |
| 16:16 |
mmorgan |
There are some view/update permissions for individual ou settings, and I know more can be added, but it seems like a staff user always sees the full list regardless of whether they have view/update permissions on the individual settings. |
| 16:16 |
* Dyrcona |
signs out for a bit, possibly for the rest of the day. Cheers, everyone! |
| 16:16 |
Bmagic |
lata! |
| 16:16 |
csharp |
Dyrcona: see ya - safe travels! |
| 16:16 |
Dyrcona |
Thanks! |
| 16:17 |
Dyrcona |
mmorgan: That sounds like a bug. |
| 16:17 |
csharp |
mmorgan: I think there's a bug open on that issue |
| 16:17 |
* mmorgan |
will go looking for a bug |
| 16:17 |
csharp |
I know that a lot of settings have to be "viewable" by staff to *do* things in the client |
| 16:17 |
csharp |
which is unexpected |
| 16:18 |
csharp |
I tried to lock down settings by giving only certain groups view perms and it created havoc |
| 16:19 |
mmorgan |
Really? That is unexpeced. |
| 16:19 |
mmorgan |
unexpected, even |
| 16:23 |
|
sandbergja_ joined #evergreen |
| 16:25 |
* mmorgan |
isn't having much luck finding that bug. |
| 16:43 |
|
Dyrcona joined #evergreen |
| 16:53 |
|
sandbergja_ joined #evergreen |
| 16:59 |
|
kmlussier joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 17:18 |
|
stephengwills joined #evergreen |
| 17:20 |
Dyrcona |
Ok. Now, I am calling it a day. Good evening, #evergreen! |
| 17:24 |
|
stephengwills joined #evergreen |
| 18:25 |
|
aabbee left #evergreen |
| 21:42 |
|
sandbergja joined #evergreen |
| 21:57 |
csharp |
cd2b70d9 |
| 21:57 |
pinesol |
csharp: [evergreen|Srey Seng] LP#1358392: See references not always displaying on browse search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cd2b70d> |
| 22:00 |
csharp |
19953de6 |
| 22:00 |
pinesol |
csharp: [evergreen|Mike Rylander] LP#1698206: Reify baseline schema - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=19953de> |
| 22:00 |
csharp |
bug 1698206 |
| 22:00 |
pinesol |
Launchpad bug 1698206 in Evergreen "Eliminate staged search" [Wishlist,Fix released] https://launchpad.net/bugs/1698206 |
| 23:31 |
|
beanjammin joined #evergreen |
