Bug 24407 - AuthDisplayHierarchies ignores new nodes and needs protection against cyclic relations
Summary: AuthDisplayHierarchies ignores new nodes and needs protection against cyclic ...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Authority data support (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-13 12:23 UTC by Marcel de Rooy
Modified: 2021-12-16 12:09 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2020-01-13 12:23:08 UTC
Suppose I have term A with children B and C where the children have a 550 tag with broader indication to A.
If I go to record A, the tree is built showing B and C.
If I add a child D to A, the tree for A is not rebuilt but still showing the old situation.

A related problem:
If I change term A setting it to a be child of B with a 550 (which it obviously not is), this cyclic relation will trigger deep recursion. Resulting in a gateway timeout and a process eating up resources..
Comment 1 Marcel de Rooy 2020-01-13 12:23:54 UTC
Katrin,
If I am not mistaken, you are using it? Could you comment on this?
Comment 2 Katrin Fischer 2020-01-13 13:15:42 UTC
(In reply to Marcel de Rooy from comment #1)
> Katrin,
> If I am not mistaken, you are using it? Could you comment on this?

Sadly not at the moment, see major bug 23190 - I can't get it to work at the moment.
Comment 3 Marcel de Rooy 2020-01-13 14:27:49 UTC
(In reply to Katrin Fischer from comment #2)
> (In reply to Marcel de Rooy from comment #1)
> > Katrin,
> > If I am not mistaken, you are using it? Could you comment on this?
> 
> Sadly not at the moment, see major bug 23190 - I can't get it to work at the
> moment.

Could it be related to the first thing mentioned here?
Comment 4 Katrin Fischer 2020-01-14 07:25:33 UTC
I am not sure - could you try my cataloging example on the other bug or tell me if it looks right to you? Really confused by this one.
Comment 5 Marcel de Rooy 2020-01-21 09:00:30 UTC
(In reply to Marcel de Rooy from comment #3)
> (In reply to Katrin Fischer from comment #2)
> > (In reply to Marcel de Rooy from comment #1)
> > > Katrin,
> > > If I am not mistaken, you are using it? Could you comment on this?
> > 
> > Sadly not at the moment, see major bug 23190 - I can't get it to work at the
> > moment.
> 
> Could it be related to the first thing mentioned here?

A closer look tells me that they are not the same.
Comment 6 Tomás Cohen Arazi 2021-12-16 12:09:18 UTC
(In reply to Marcel de Rooy from comment #0)
> Suppose I have term A with children B and C where the children have a 550
> tag with broader indication to A.
> If I go to record A, the tree is built showing B and C.
> If I add a child D to A, the tree for A is not rebuilt but still showing the
> old situation.

What you're saying is that if you sit on the parent, it doesn't have a way to know a new child showed up, and you're proposing some automatic bi-directional linking? I like this.

> A related problem:
> If I change term A setting it to a be child of B with a 550 (which it
> obviously not is), this cyclic relation will trigger deep recursion.
> Resulting in a gateway timeout and a process eating up resources..

Had to deal with this in production. I wrote a tiny script that does a DFS to find cycles from a leaf, following the $wg path (the $wh are not considered in most of the code as far as I can tell.)