Hi, After upgrading from 2.7.1 to 3.0.0 Beta I note the following:
In trying to create most infrastructure items the following error occurs:
Error: Error: Circular dependencies between the fields!
Array
(
[managementip_id] => Array
(
[1] => managementip_id
)
)
Me too, i have error it.
When i try to create ticket request, system show error:
Error: Error: Circular dependencies between the fields!
Array
(
[reporter_id] => Array
(
[0] => reporter_id
)
)
With my geometry extension, I have this error in 3.0.0 when I try to add a layer source to a map (AttributeLinkedSetIndirect)
Is this a known issue somehow? Not sure what makes it different from other AttributeLinkedSetIndirect attributes.
Sorry: I realized too late it's in the wrong forum and I can't move the post.
The UIWizard gets constructed with a NULL value for page. Currently as far as I have seen, the wizard helper always calls UIWizard with a NULL value for $oPage.
https://github.com/Combodo/iTop/blob/8dd96ea636a8f9b8045de31e76c53459f69d1c5f/application/wizardhelper.class.inc.php#L283
Perhaps there's something wrong with my custom linked class (working in 2.7 though), but this error can certainly not popup since the page object is always null:
Anyhow, if I uncomment that line about circular reference, my remaining "bad" fields is the friendlyname, which uses the two names of the object:
Relevant XML parts of this linked class:
Last edit: Jeffrey Bostoen 2021-04-22
For me, this works as soon as I change the naming to use olsource_id and olmap_id
However, in iTop 2.7 it works fine with olsource_name and olmap_name
In this case, it seems to be related to using external fields in the naming
I don't see significant differences in iTop 2.7.4 and iTop 3.0.0 beta in uiwizard.class.inc.php and wizardhelper.class.inc.php . Perhaps it occurs in another method?
Anyhow, the UI Wizard still seems buggy, as I don't see where the "page" object would not be null.
For me, the issue seems to be with the "friendlyname".
With iTop 2.7.4, right above the
while(count($aFields) > 0)
, if I output $aFields: it has no dependencies to olmap_name and olmap_source.With iTop 3.0.0 beta, it still has those two fields as a dependency.
Last edit: Jeffrey Bostoen 2021-04-28
Further debugging: the result of $oAttDef->GetPrerequisiteAttributes() in the "now computes the steps to fill the optional fields" loop seems to give different results in iTop 2.7.4 vs iTop 3.0.0 for the "friendlyname" attribute.
In iTop 2.7.4, it's empty.
In iTop 3.0.0, it lists the olsource_name and olmap_name.
In attributedef, there do not seem to be changes to this method for AttributeFriendlyName. Have things changed on "depends on"?
Last edit: Jeffrey Bostoen 2021-04-29
Hi, can you give us a step by step procedure to reproduce this? I couldn't on my 3.0 instance when creating a user request or a cluster.
Also can you give us your webserver (eg. Apache, nginx) and your PHP version?
Thanks!
Guillaume
Last edit: Guillaume Lajarige 2021-04-22
HI Guillaume,
These are the steps.
1. Upgrade to version 3 from 2.7.1
2. Try to create an infrastructure item such as a network device or server, or San Switch
If this is done we get Array
Array
(
[managementip_id] => Array
(
[1] =>managementip_id
)
)
Last edit: R Panton 2021-04-22
Thanks for the steps, unfortunately I still cannot reproduce... 😕
I'm assuming this is used in combination with (latest version?) of TeemIP
I assume it happens when for naming an ID field is used.
The actual error is because it tries to render the error message on a non-existing (always NULL for now) page object.
Last edit: Jeffrey Bostoen 2021-04-22
How can we correct this then?
Hello Jeffrey, I saw your comment but how can it not happen on our instances, I don't get it. I didn't checked the value of $oPage yet, but I can't make it crash.
Is there a way to verify if we're even using the exact same beta version?
I think it happens on certain classes with certain ID fields in the naming (possible AttributeExternalKey or perhaps AttributeExternalField)
I am using beta 3.0.0 - 7312
You can get your iTop version in the backoffice by clicking the user icon at the bottom of the navigation menu, then "About iTop".
Hello everyone,
This has been tracked in our bug tracker (no fix yet) for it to be fixed before the 3.0 RC.
Thank you very much for your feedbacks!
Cheers,
Guillaume
Hi Jeffrey.
Thanks to your investigations, I found out that I could reproduce with a minimal customization.
In my case, I have changed the friendly name of the class lnkContactToTeam so that it relies on contact_id_friendlyname + team_id_friendlyname, rather than contact_id + team_id.
The associated use case is : edit or create a person, change the organization... the location attribute is being reloaded... nothing happens and error.log exhibits the exact same error as the one you encountered:
Hello everybody,
We committed a fix for the minimal custo Romain talked about. If one of you is confortable enough with GitHub and cloning the latest code base, could you try again and tell us if the issue is still there ?
Thanks!
Guillaume
Hello everyone,
This should be resolved and part of the beta2 that just rolled out!
Cheers,
Guillaume