#29026 [Form] fix: selectForForms issue for manage case where objectdesc don't need to reset

[nicolas-eoxia]

Field from class we want use selectForForms functions

Error occured because type integer not integer:Product......

Fix with check and reset value

Add preg_match for check before preg_replace
Add reset objectdesc to default value

[eldy]

Can you paste the code of ->fields inside the object "session formation" ?

[nicolas-eoxia]

All fields from Session class

Indeed fk_element type is integer but in create or edit action i want upate fk_element type by this on capture

The reel problem here is on selectForFroms functions L8050

$objectforfieldstmp = fetchObjectByElement(0, strtolower($tmparray[0]));

the object is retrieved without taking into account modifications to the current object and with id = 0
As a result, after this line we have a fresh object

[eldy]

OK. My understanding is that in your object SessionFormation, you set dynamically the array fields to have the correct definition of the link "Service". Not common, and not designed for initially but why not. However, if we are able to have code working for the link when definition is static, we should be able to have same result (code working) when code is dynamically set, with no need to change code. This is why i think fix is suspicious.

fetchObjectByElement(0, strtolower($tmparray[0])); is done with id = 0 because all what we want is an instance of object of the good type (so for you you should get "Product") to be able to reuse later the ->$fields;

What do you have for value in
$objectdesc
$objectfield
$tmparray[0]
$tmparray[1]

[nicolas-eoxia]

Here are the values of the variables requested

I agree with the fact that defining a fields link statically or dynamically should not lead to modification, but the problem comes from the fresh object, which doesn't use dynamic modification.

The fix I'm proposing makes it possible to check that there is a link before making a replacement

Otherwise you reset to the initial value

$objectdesc => Product L8044
$objectfield => trainingsession@dolimeet:fk_element L8045
$tmparray[0] => trainingsession@dolimeet L8050
$tmparray[1] => fk_element L8050

$objectforfieldstmp =>

Trainingsession Object ->
[fk_element] => Array
(
[type] => integer
[label] => FkElement
[enabled] => 1
[position] => 92
[notnull] => 0
[visible] => 1
[index] => 1
[css] => maxwidth500 widthcentpercentminusxx
[csslist] => left
)

[FHenry]

@eldy We've change base branch.
What do you think ?

EDIT: finaly we reset to 19.0 because we prefer wait your input

[eldy]

OK.
So the entry parameter are correct.
$objectdesc => Product L8044
$objectfield => trainingsession@dolimeet:fk_element L8045

The goal of the selectForForms is to use the field key "fk_element" extracted from $objectfield to retreive into trainginsession@dolimeet->fields["fk_element"] what is the object we want for the combo list (the parent object of fk_element. Here, we hope to get Product).

Here it fails because selectForForms is calling fetchObjectByElement('trainingsession@dolimeet') to get the parent object from the defintion inside TrainingSession, but fetchObjectbyelement is not working on the dynamic value you modified before, it makes a new $... so the object is a new one and the ->fields inside is also a new one, not modified dynamically, so not in phase.

So, for me, the trouble should not be fixed on line 8070, but at the nearest line (the first line) where the deviance appears, so into fetchObjectByElement(), because fetchObjectByElement() return a data with no difference when you made dynamic modifications or not, you are later in the sh.... So later, you introduce some tests to retreive the correct information differently, but with no specific parameter, this let me think this decision will also occurs when it should not.

So i suggest to try this:

First, I suggest into your trainginsession class file, into ->fields['fk_element'] instead of having
... 'type' => 'integer', ...
I suggest to have
... 'type' => 'integer:NotPredeclaredClass:notpredeclaredpath'

This syntax is the one expected by dolibarr now, and the one when generating an object with module builder (except that instead of the name of class you put the hardcoded string "NotPredeclaredClass".
Like this, things are clear we are in a situation we want to use a parent object that is dynamically defined. And we will be able to adapt the framework to be able to manage this case with no side effect for common cases.

Then into the selectForForms, you can change the code

if (empty($objectdesc)) {
					$objectdesc = $objectdescorig;
}

into

if (strpos("NotPredeclaredClass", $objectdesc) === 0) {
					$objectdesc = $objectdescorig;
}

This way, it is clear that the test to fallback is only for special cases you are in.

Can you try this way ?
I did not test, it is just an idea to validate (we may need to add the test if NotPredeclaredClass at other places in code but at least we will know every places where the management of dynamic fields need special adaptation)...

Note: As this is a developer feature not used in a conventionnel way (it was initially not thinking for dynamic use), we must introduce a solution, but this can only be in develop.