You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hiding fields depending on category does not work #847
When I setup a block to be hidden depending on ticket category, block is not hidden in simplified interface. Haven't tried in standard interface since it does not meet our requirements.
Block configuration:
Block fields:
Block hiding condition:
When a user begins to create a ticket, block is shown (which is expected to happen)
But when the user sets the category by which the block has to be hidden, some erratic movement happens and the field is still shown with broken CSS, a.k.a. moved rightwards and wider.
I've tried setting the condition to the ticket's title and this works correctly, block is successfully hidden and works like a charm.
Relevant log output
No response
Page URL
No response
Steps To reproduce
Create a block and set it's type to "Insertion in the form (before save button)".
Configure some fields in the block.
Set a hiding conditional rule that depends on ticket's category.
Test a ticket creation by setting the category specified on step 3 and block is still present.
I was having the same issue. And I, so called "fixed" it.
In field.class.php I added || strpos($current_url, 'tracking.injector.php') !== false to the if statements.
Because, when you start using ticket form - your address is not 'helpdesk.public.php' anymore it's 'tracking.injector.php'
There, if we don't have type in $item or we don't have itilcategories_id- we got them from $params options.
This will fix all issues with containers, and you will be able to show or hide them according to your conditions.
If there is a better way to fix this issue - tell me.
Hi! I've tried the code, but it didn’t work as expected in my case. I had to move a few lines of your code further down in fields.inc.php to make it work properly.
The issue seemed to be related to this part of the code:
if ($item->isEntityAssign()) {
$current_entity = $item->getEntityID();
if (!in_array($current_entity, $entities)) {
return;
}
}
I’m not entirely sure what this block was doing, but in my case it was preventing the code from working as expected — the values assigned by @akstis-typer snippet were overriden once again to empty values.
There has been no activity on this issue for some time and therefore it is considered stale and will be closed automatically in 10 days.
If this issue is related to a bug, please try to reproduce on latest release. If the problem persist, feel free to add a comment to revive this issue.
If it is related to a new feature, please open a topic to discuss with community about this enhancement on suggestion website.
Activity
DaviidMM commentedon Jan 13, 2025
Still having this issue...
akstis-typer commentedon Apr 10, 2025
I was having the same issue. And I, so called "fixed" it.
In field.class.php I added
|| strpos($current_url, 'tracking.injector.php') !== falseto the if statements.Because, when you start using ticket form - your address is not 'helpdesk.public.php' anymore it's 'tracking.injector.php'
This will fix the alignment issue.
Next, I edited showForTab function like so
There, if we don't have type in $item or we don't have itilcategories_id- we got them from $params options.
This will fix all issues with containers, and you will be able to show or hide them according to your conditions.
If there is a better way to fix this issue - tell me.
stonebuzz commentedon Apr 10, 2025
Hi @akstis-typer
can you propose a PR ?
DaviidMM commentedon Apr 10, 2025
Hi! I've tried the code, but it didn’t work as expected in my case. I had to move a few lines of your code further down in
fields.inc.phpto make it work properly.The issue seemed to be related to this part of the code:
I’m not entirely sure what this block was doing, but in my case it was preventing the code from working as expected — the values assigned by @akstis-typer snippet were overriden once again to empty values.
Hope this helps!
github-actions commentedon May 21, 2025
There has been no activity on this issue for some time and therefore it is considered stale and will be closed automatically in 10 days.
If this issue is related to a bug, please try to reproduce on latest release. If the problem persist, feel free to add a comment to revive this issue.
If it is related to a new feature, please open a topic to discuss with community about this enhancement on suggestion website.
You may also consider taking a subscription to get professionnal support or contact GLPI editor team directly.
trasher commentedon May 23, 2025
@DaviidMM please try fix proposed in #942