Fixed issue with hiding conditions not hiding containers in simple ticket view#942
Fixed issue with hiding conditions not hiding containers in simple ticket view#942akstis-typer wants to merge 1 commit into
Conversation
akstis-typer
commented
Apr 10, 2025
- It fixes Hiding fields depending on category does not work #847
|
Just to clarify: in my fresh installation (latest versions of everything), I had to place the code inside the $display_condition = new PluginFieldsContainerDisplayCondition();like this: ...
$display_condition = new PluginFieldsContainerDisplayCondition();
// @akstis-typer code starts here ------
if($item->fields['type'] == "")
{
$item->fields['type'] = $params['options']['type'];
}
if($item->fields['itilcategories_id'] == "")
{
$item->fields['itilcategories_id'] = $params['options']['itilcategories_id'];
}
// @akstis-typer code ends here ------
if ($display_condition->computeDisplayContainer($item, $c_id)) {
...Otherwise, it didn’t work properly in my environment |
|
I've been testing this code and works correctly except for one more issue: When a custom field is shown and you edit another field (e.g. title), the custom field's alignment breaks again. My solution was to add $display_condition = new PluginFieldsContainerDisplayCondition();
if ($display_condition->computeDisplayContainer($item, $containers_id)) {
$field_options = [
'label_class' => 'col-lg-3',
'input_class' => 'col-lg-9',
];
echo "<div class='offset-md-1 col-md-8 col-xxl-6'>";
PluginFieldsField::showDomContainer(
$containers_id,
$item,
$type,
$subtype,
$field_options
);
echo "</div>";
} else {
echo '';
}After the |
|
can you rebase ? |
Hi, you mean I need to add last changes of original repository? Or something else? |
That should be sufficient. |
|
I think I did it right. The next step is unit tests - how do I make them? Or can I run yours? |
trasher
left a comment
There was a problem hiding this comment.
You PR has lot of unrelated changes (new lines added, spacing added/removed) that must be reverted.
|
I've done poorly last time and accidentally revert changes in twig files. Now I reverted all back how it should be and removed spaces and new lines I added. |
Rebased myself to upstream main branch Edited only two files: -container.php that fixes formatting of field -field.class.php that fixes issue with field not respecting hiding condition in simple view
|
Finally I got it |
We currently have no tests on this plugin; but we will work on adding some quickly. For now, you cannot add tests for your changes; we'll ping you. Until that, we asked feedback from several users to know if their issues are resolved by your changes. Thanks a lot for your worK. |
|
=
I tested it and in my environment it only worked correctly this way. Thank you very much everyone! |
ae44e4d to
4a06ac1
Compare
|
It seems that there are many unrelated changes included in this PR. |
|
My bad. I'll get rid of unnecessary changes |
|
Great, congratulations! |
|
Hi, @leeopereira, my fix doesn't work on the nightly version of the plugin? |
Oi @akstis-typer , Unfortunately not, I had to restore a backup of the previous version of the files. When I updated, the deleted files were replaced with the originals from the new version, and the problem returned. The hide condition stopped working, and the custom fields became misaligned. :/ |
|
@leeopereira , this happened because this changes are not in the main branch of fields plugin repo, so when you update using glpi - they getting overriden by update that developers made. |
|
@akstis-typer After updating, I tried editing the files and inserting the corrections here in the topic, but it still didn't work. I don't know if they changed something in the code that impacted the correction. But I just returned the two old edited files and it worked. |
| $field_options = [ | ||
| 'label_class' => 'col-lg-3', | ||
| 'input_class' => 'col-lg-9', | ||
| ]; | ||
| echo "<div class='offset-md-1 col-md-8 col-xxl-6'>"; | ||
| PluginFieldsField::showDomContainer( | ||
| $containers_id, | ||
| $item, | ||
| $type, | ||
| $subtype, | ||
| $field_options, | ||
| ); | ||
| echo "</div>"; |
There was a problem hiding this comment.
This wrapper is now always applied on AJAX refresh, but showForTab (inc/field.class.php:965-974) only applies it for helpdesk.public.php/tracking.injector.php. Normal admin/agent forms load with no wrapper, then get re-wrapped as soon as any field changes ; fields shift after the first edit. Matches misalignment reports on the PR thread (e.g. leeopereira, 2025-08-28).
Should this only apply when $type/$subtype matches the public/injector context, like showForTab?
| if ($item->fields['type'] == "") { | ||
| $item->fields['type'] = $params['options']['type']; | ||
| } | ||
| if ($item->fields['itilcategories_id'] == "") { | ||
| $item->fields['itilcategories_id'] = $params['options']['itilcategories_id']; | ||
| } |
There was a problem hiding this comment.
post_item_form is a global hook, fired for all 70+ itemtypes, not just Ticket. Most have no type/itilcategories_id column (even Change/Problem lack type), so this raises "Undefined array key" warnings on nearly every item's edit form.
| if ($item->fields['type'] == "") { | |
| $item->fields['type'] = $params['options']['type']; | |
| } | |
| if ($item->fields['itilcategories_id'] == "") { | |
| $item->fields['itilcategories_id'] = $params['options']['itilcategories_id']; | |
| } | |
| if ($item instanceof Ticket) { | |
| $item->fields['type'] = $item->fields['type'] ?: ($params['options']['type'] ?? ''); | |
| } | |
| if ($item instanceof CommonITILObject) { | |
| $item->fields['itilcategories_id'] = $item->fields['itilcategories_id'] ?: ($params['options']['itilcategories_id'] ?? ''); | |
| } |
Can you test with a non-ITIL item (e.g. Computer)? No test covers this method.