| Time |
Nick |
Message |
| 03:33 |
|
dbwells joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
Dyrcona joined #evergreen |
| 07:22 |
|
rfrasur joined #evergreen |
| 07:30 |
|
dbwells joined #evergreen |
| 07:39 |
Dyrcona |
bshum++ # Resetting karma and starting on Ubuntu 20.04. |
| 07:58 |
|
dbwells joined #evergreen |
| 08:31 |
|
mmorgan joined #evergreen |
| 08:38 |
|
mantis1 joined #evergreen |
| 08:44 |
|
Stompro joined #evergreen |
| 09:07 |
|
dbwells joined #evergreen |
| 09:12 |
|
alynn26 joined #evergreen |
| 09:36 |
|
Stompro joined #evergreen |
| 10:05 |
|
jvwoolf joined #evergreen |
| 10:46 |
|
sandbergja joined #evergreen |
| 11:28 |
* Dyrcona |
thinks getting Evergreen working on an O/S without systemd is a good idea. I just saw systemd-journal using 100% cpu because my training server ran out of cstore drones. I guess the journal process couldn't keep up with the log spew? |
| 11:53 |
|
sandbergja joined #evergreen |
| 12:01 |
Dyrcona |
@karma |
| 12:01 |
pinesol |
Dyrcona: Highest karma: "Evergreen" (1) and "bshum" (1). Lowest karma: "Evergreen" (1) and "bshum" (1). |
| 12:01 |
Dyrcona |
:) |
| 12:01 |
berick |
eh |
| 12:01 |
berick |
heh |
| 12:01 |
bshum |
So where's systemd minus? :D |
| 12:01 |
|
jvwoolf1 joined #evergreen |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:07 |
|
mrisher joined #evergreen |
| 12:14 |
Dyrcona |
systemd-- |
| 12:14 |
Dyrcona |
:) |
| 12:15 |
Dyrcona |
berick: I think you are right about the timeout. I'll have to do some more testing later. |
| 12:28 |
|
mrisher joined #evergreen |
| 12:31 |
|
mantis1 joined #evergreen |
| 12:32 |
|
genpaku joined #evergreen |
| 12:32 |
|
rhamby joined #evergreen |
| 12:32 |
|
agoben joined #evergreen |
| 12:32 |
|
Guest78715 joined #evergreen |
| 12:32 |
|
awitter joined #evergreen |
| 13:13 |
mmorgan |
Is there any chance bug 1482757 can make it into 3.5? Would it be considered a bug fix? |
| 13:13 |
pinesol |
Launchpad bug 1482757 in Evergreen 3.1 "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
| 13:25 |
mmorgan |
^^miker, berick, csharp, anyone? |
| 13:29 |
|
rhamby joined #evergreen |
| 13:29 |
|
agoben joined #evergreen |
| 13:29 |
|
Guest78715 joined #evergreen |
| 13:29 |
|
awitter joined #evergreen |
| 13:29 |
|
mantis1 joined #evergreen |
| 13:45 |
|
jihpringle joined #evergreen |
| 14:24 |
|
jvwoolf joined #evergreen |
| 14:27 |
jvwoolf |
We've got another mystery involving reports. Users with library staff permissions can't clone templates in the web client. All fields come up blank, including the report title and description. Cloning still works for them in XUL. Superusers can clone any template in the web client. Has anybody come across this issue before? |
| 14:27 |
jvwoolf |
Version 3.1.16 |
| 15:02 |
|
rfrasur joined #evergreen |
| 15:17 |
|
mikerisher joined #evergreen |
| 15:26 |
|
mrisher joined #evergreen |
| 15:31 |
|
mantis1 left #evergreen |
| 15:41 |
mmorgan |
jvwoolf: Can those users create new templates? |
| 15:46 |
jvwoolf |
mmorgan: Yes, they have those permissions. |
| 15:47 |
jvwoolf |
And the template creator screen loads, but it doesn't fill in with the info on the cloned template |
| 16:15 |
mmorgan |
jvwoolf: And this happens for any template they try and clone? |
| 16:15 |
jvwoolf |
Yes. Doesn't seem to matter who clones it. |
| 16:16 |
mmorgan |
Doesn't matter who owns the original template either? |
| 16:39 |
jvwoolf |
mmorgan: No, doesn't seem to matter. |
| 16:39 |
jvwoolf |
I had that thought, but they can't clone templates owned by users in the same group as them. |
| 16:40 |
jvwoolf |
(Though most of our templates are owned by superusers) |
| 16:43 |
mmorgan |
What's the depth of the reports permissions for the library staff permission group? |
| 16:44 |
mmorgan |
I assume you've tried clearing cache and all that? |
| 16:49 |
jvwoolf |
mmorgan: Hm, looks like CREATE_REPORT_TEMPLATE was on the system level |
| 16:51 |
jvwoolf |
I'm going to try changing it to consortium and see if that makes a difference |
| 16:52 |
mmorgan |
That's what our users have, and we haven't seen that problem. We're on 3.3.5. |
| 16:55 |
mmorgan |
jvwoolf: There's this bug, but it should have been fixed for 3.1.16: bug 1845050 |
| 16:55 |
pinesol |
Launchpad bug 1845050 in Evergreen 3.3 "reporter interface can fail to completely load" [High,Fix released] https://launchpad.net/bugs/1845050 |
| 16:56 |
jvwoolf |
mmorgan, Your users have permission on the system level? |
| 16:56 |
mmorgan |
Yes, they do. |
| 16:57 |
mmorgan |
Did changing to cons depth solve the problem? |
| 16:57 |
jvwoolf |
Still working on it. |
| 16:57 |
jvwoolf |
GUI permission group editor doesn't always play nice :) |
| 16:58 |
mmorgan |
Yeah :) |
| 17:01 |
jvwoolf |
Looks like no, even after clearing cache |
| 17:01 |
jvwoolf |
Not sure if that bug would have affected us. We're on Ubuntu Xenial. |
| 17:07 |
jvwoolf |
mmorgan: Thanks for your suggestions. Will have to dig into this again tomorrow. |
| 17:07 |
jvwoolf |
mmorgan++ |
| 17:08 |
* mmorgan |
is out of ideas for today, and needs to sign out too. Tomorrow is another day... |
| 17:08 |
|
mmorgan left #evergreen |
| 17:15 |
jeffdavis |
Looking at bug 1873048, I tried adding a retrieve perm with context_field for booking resource types in fm_IDL.xml, but I could still retrieve resource types owned by libraries where I didn't have the retrieve perm. If I don't have the retrieve perm at the context_field, shouldn't I be prevented from retrieving the object? |
| 17:15 |
pinesol |
Launchpad bug 1873048 in Evergreen 3.4 "Booking - Resource Type drop down should limit choices by owning library" [High,Confirmed] https://launchpad.net/bugs/1873048 |
| 17:24 |
jeffdavis |
I need a pinesol plugin that posts all my questions 3 hours earlier, before the east coast folks have signed off for the day. |
| 17:49 |
bshum |
@later [someone] Hello! :D |
| 17:49 |
pinesol |
bshum: did you finish your beer? |
| 17:49 |
bshum |
Haha |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:41 |
|
sandbergja joined #evergreen |
| 19:24 |
|
sandbergja joined #evergreen |
| 21:22 |
|
sandbergja joined #evergreen |
| 22:02 |
|
sandbergja joined #evergreen |
| 22:45 |
|
sandbergja_ joined #evergreen |
| 23:17 |
|
sandbergja joined #evergreen |
