| Time |
Nick |
Message |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 07:39 |
|
collum joined #evergreen |
| 08:20 |
|
BDorsey joined #evergreen |
| 08:48 |
|
jvwoolf joined #evergreen |
| 09:06 |
|
Dyrcona joined #evergreen |
| 09:14 |
|
mantis1 joined #evergreen |
| 09:21 |
|
rfrasur joined #evergreen |
| 09:52 |
|
jmurray-isl joined #evergreen |
| 09:57 |
Bmagic |
I've got a problem with the 3.8.0->3.9.0 sql upgrade. It's bombing when INSERT INTO asset.copy_inventory. Specifically the called function: asset.copy_may_float_to_inventory_workstation(). One of my copies is not allowed to float to the org unit assigned to the workstation |
| 10:00 |
Bmagic |
It seems I need to pre-edit asset.latest_inventory... maybe a custon function to find the rows that would throw this error and edit the workstation to an ID that is equal to asset.copy.circ_lib? |
| 10:13 |
|
rjackson_isl_hom joined #evergreen |
| 10:33 |
|
stephengwills joined #evergreen |
| 11:22 |
|
rjackson_isl_hom joined #evergreen |
| 11:24 |
Dyrcona |
Bmagic: You could delete those latest_inventory entries if they are not the most recent entry. That table was meant, I think, to have only 1 row per copy in it. |
| 11:26 |
Bmagic |
I ended up editing the trigger function temporarily, to return a random row of a workstation that matched the item circ_lib in the case where it was floating and wasn't allowed to float to that workstation owning_lib |
| 11:26 |
Dyrcona |
Bmagic: Your idea should work, though. |
| 11:26 |
Bmagic |
then do the insert, then put the function back to standard |
| 11:26 |
Bmagic |
that did "work" and get me passed that error |
| 11:26 |
Dyrcona |
Well, that works, but I would have done a pre update on the table. |
| 11:27 |
Dyrcona |
TIMTOWTDI! |
| 11:28 |
Bmagic |
haha |
| 11:37 |
Dyrcona |
Those rows probably should have been deleted now that I've thought about it for 5 minutes. They aren't allowed by the new rules, and I don't think they should have been allowed before. |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:41 |
|
collum joined #evergreen |
| 12:44 |
|
collum joined #evergreen |
| 14:11 |
|
jihpringle joined #evergreen |
| 15:14 |
mantis1 |
Does anyone have any ideas on how to prevent spam bots from spamming self registration pages? |
| 15:18 |
Dyrcona |
mantis1: Find out if they're coming from any particular geographical location and block those IP ranges, at least for self registration. |
| 15:19 |
Dyrcona |
You could try adding a robots.txt entry with a disallow on the self-registration URL, but I doubt the spam bots will obey it. |
| 15:21 |
Dyrcona |
mantis1: This might be helpful for my previous suggestion: https://www.nirsoft.net/countryip/index.html |
| 15:29 |
mantis1 |
Dyrcona: can I get that informatin from looking at the gateway files? |
| 15:29 |
mantis1 |
We haven't tried tracking for self reg specifically before |
| 15:30 |
Dyrcona |
mantis1: Well, I'd use the Apache logs assuming that mod_remoteip is set up properly. You might find it in the nginx logs, but I don't think our suggested configuration logs very much. |
| 15:30 |
Dyrcona |
Self reg. probably doesn't go through the OSRF gateway. |
| 15:32 |
Dyrcona |
One thought I had while searching my browser history for the nirsoft page was to set up a configuration in nginx for the self reg. URL that does a deny all, and then allows only IPs from the USA to connect. |
| 15:33 |
Dyrcona |
I don't know if you could find a range of IPs restricted to Connecticut, but if that existed, it would be even better. |
| 15:36 |
mantis1 |
Thank you for your help! |
| 15:36 |
mantis1 |
Dyrcona++ |
| 15:39 |
Dyrcona |
mantis1: Hope it helps! |
| 16:19 |
|
jvwoolf left #evergreen |
| 18:12 |
|
rjackson_isl_hom joined #evergreen |
| 20:00 |
|
dbs joined #evergreen |
