Problem triggering a rule with Category Field

leonardo.evaldt · 2025-01-15 02:01:53

Hi everyone.

I am struggling with a "configuration" in GLPI and was wondering if someone could help me with an alternative.

I created a business rule for a ticket that has two criteria: validation is granted and the category is "option 1". If the criteria are met, the action X is executed.

The self-service user fills in the category field and the supervisor user validates the ticket. And my rule doesn't work.

After some digging, I found this in the GLPI manual:

Note

Business rules for tickets can be played when opening and/or updating tickets depending on the parameter defined in the rule. During the update, only the modified fields (by the action on the ticket or by the rules previously executed) trigger the rules. Thus a rule having criteria corresponding to unmodified fields will not be executed.

Only fields changed at the same time can trigger a rule.

To solve this problem, I thought: I could hide the category field from the self-service user and let the supervisor choose it, but the GLPI doesn't allow this field "Category" to be hidden from any profile.

To solve this, I thought: I could create another field (a custom one) so I could hide it from the self-service user but not from the supervisor, who would change it, triggering the rule. But the GLPI does not offer the possibility to hide custom fields too.

Anyone have any idea how can I make my rule work since I need these two criteria to be considered?

OBS: Asking the self-service user not to fill in the field Category is not an option. As you IT guys well know, users always do things they are not supposed to.

OBS2: After some thinking, I reach the conclusion that the problem is this: "a rule having criteria corresponding to unmodified fields will not be executed". It is well known that self-service users will fill in some fields and the supervisors will fill in others, so the rules that can be created are absolutely restricted. This can't be intentional. Doesn't make sense. Why create a lot of profiles if the rules cannot be applied for the separated job that they do?

Thanks all.

cconard96 · 2025-01-15 13:00:25

A few clarifications:

1. Yes, business rule criteria only account for the changes being made. It is a way to say if for example you change the category to "Security", you can automatically assign the "Security Team" group. If it accounted for the existing fields, the rules would re-run every single time the criteria matched and that could be unexpected behavior.
2. The category and request type fields for tickets are always shown because they can trigger changing the ticket template used. If one template hid these fields, you could get stuck with that template and have no way to change it.
3. You can hide categories by making them only visible in the standard interface.
4. Yes, the rules engine is limited but it is still powerful on its own as long as you don't expect it to be a full workflow solution. For info, there IS a workflow feature on the roadmap for GLPI but I don't have an ETA. For the rules engine to support more complex scenarios that allow differentiating changed vs existing fields, it would require a rewrite I think for it to work properly.
5. Rules aren't about different actions for different profiles. Profiles are sets of permissions that can be applied for different entities. There is a UserEcho request to be able to hide fields in templates based on the interface (simplified/standard), but it hasn't been accepted or implemented yet and I doubt it will be picked up for GLPI 11.0 as we are already close to release and have other features to finish. You can increase visibility of this community suggestion by upvoting it.

https://glpi.userecho.com/communities/1 … -interface

leonardo.evaldt · 2025-02-26 16:52:30

1. I understand your point but doesn't agree that the present situation is the best solution. But I found an around solution for this. I created a rule that clear the "Category" field, so, no matter what the self-service user do in this field, it will always be erased after the ticket be opened. Solve the problem for me. If anyone have the same problem with this field "Category", this around solution works just fine.

2. It is in fact a good tool. But it could be optional, not mandatory.

3. Unfortunately it does not work because after opening a ticket, a self service user can use the standart interface to follow the ticket changes, and there he is allowed to see the categories and change then. There is no way to hide the categories from him in the standard interface. But there is a way to forbid him from update the important block of fields in administration\profiles\assistance\ticketc. So, problem solved....

4. I understand the excellent work you developers are doing in GLPI. Hoping the improvements keep caming...

5. A way to choose what can be hidden, by field, would be amazing. The way it is now, is very restrictive...

A have new problems but I will use another topic for my other questions. I appreciate your effort to help clarify me these things.
Thanks for the reply.

PS: in the link you provided in your reply (userecho) there is a comment about the "hidefields" plugin. But it wasn't upgraded to GLPI 10. There is an interest or even a forecast for thit upgrade?

Last edited by leonardo.evaldt (2025-02-26 17:03:47)

Forum GLPI-Project

Announcement

#1 2025-01-15 02:01:53

Problem triggering a rule with Category Field

#2 2025-01-15 13:00:25

Re: Problem triggering a rule with Category Field

#3 2025-02-26 16:52:30

Re: Problem triggering a rule with Category Field

Board footer