Skip to content

Hiding fields depending on category does not work #847

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
2 tasks done
DaviidMM opened this issue Oct 15, 2024 · 6 comments · May be fixed by #942
Open
2 tasks done

Hiding fields depending on category does not work #847

DaviidMM opened this issue Oct 15, 2024 · 6 comments · May be fixed by #942
Labels

Comments

@DaviidMM
Copy link

Code of Conduct

  • I agree to follow this project's Code of Conduct

Is there an existing issue for this?

  • I have searched the existing issues

GLPI Version

10.0.15

Plugin version

1.21.15

Bug description

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 config 1

Block fields:

Block fields

Block hiding condition:

Block condition
Block condition 2

When a user begins to create a ticket, block is shown (which is expected to happen)

Ticket creation before setting category

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.

Ticket creation after setting category

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

  1. Create a block and set it's type to "Insertion in the form (before save button)".
  2. Configure some fields in the block.
  3. Set a hiding conditional rule that depends on ticket's category.
  4. Test a ticket creation by setting the category specified on step 3 and block is still present.

Your GLPI setup information

No response

Anything else?

No response

@DaviidMM
Copy link
Author

Still having this issue...

@akstis-typer
Copy link

akstis-typer commented 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') !== 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'

if (strpos($current_url, 'helpdesk.public.php') !== false || strpos($current_url, 'tracking.injector.php') !== false) {
            echo "<div id='{$html_id}' class='card-body row mx-0' style='border-top:0'>";
            echo "<div class='offset-md-1 col-md-8 col-xxl-6'>";
            $field_options = [
                'label_class' => 'col-lg-3',
                'input_class' => 'col-lg-9',
            ];
        } else {
            echo "<div id='{$html_id}'>";
        }
        $display_condition = new PluginFieldsContainerDisplayCondition();

        if ($display_condition->computeDisplayContainer($item, $c_id))
        {
            self::showDomContainer(
                $c_id,
                $item,
                $type,
                $subtype,
                $field_options ?? [],
            );
        }
        if (strpos($current_url, 'helpdesk.public.php') !== false || strpos($current_url, 'tracking.injector.php') !== false) {
            echo '</div>';
        }

This will fix the alignment issue.

Next, I edited showForTab function like so

public static function showForTab($params)
    {
        $item = $params['item'];

        if($item->fields['type'] == "")
        {
            $item->fields['type'] = $params['options']['type'];
        }
        if($item->fields['itilcategories_id'] == "")
        {
            $item->fields['itilcategories_id'] = $params['options']['itilcategories_id'];
        }

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
Copy link
Contributor

Hi @akstis-typer

can you propose a PR ?

@DaviidMM
Copy link
Author

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.

 public static function showForTab($params)
    {
        $item = $params['item'];

        $functions = array_column(debug_backtrace(), 'function');
        ...
        $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)) {
        ...

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.

Hope this helps!

Copy link

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.

@github-actions github-actions bot added the Stale label May 21, 2025
@trasher
Copy link
Contributor

trasher commented May 23, 2025

@DaviidMM please try fix proposed in #942

@trasher trasher added bug and removed Stale labels May 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants