Will tickets opened by other users be released by default to requesters? GLPI 11 rc5
Closed this issue · 6 comments
Code of Conduct
- I agree to follow this project's Code of Conduct
Contribution description
Good afternoon, everyone. I have a question here that I don't know if it's a bug or a feature that hasn't been developed properly:
I noticed that in the new version of the form, this feature has been activated, opening a ticket for myself or another user.
Well, I noticed that it is also active in the applicant view (self-service). I checked the profile permissions and the global and/or entity settings, and apparently there is no way to disable this button (in my opinion, it should be optional).
It allows you to open a ticket for another user, and the ticket remains visible after it is opened for the user who opened it, even on behalf of another user.
If it is something that cannot be disabled, it will have an impact in some scenarios because, although it is a discreet button, there are several types of operations in GLPI, such as companies where the ticket is opened by an external customer, etc. In my opinion, this should be an optional checkbox on the form (which makes more sense).
I also looked in the form settings to see if there was anything I could disable, but I couldn't find anything. I noticed that when creating a new form, it automatically creates this open button called by myself or someone else.
Version : GLPI 11 Rc5
Hello, this feature is not entirely related to forms (it already existed in GLPI 10 but was hidden when you used formcreator).
This is what we call "delegation" and it is only active if you are the delegatee of a group:
Hey @AdrienClairembault , I tested it here and it's true that if the person is in a group, it unlocks that box. But in my opinion, this should be disregarded, just like in version 10. It could be left as an optional question, and if the person wants to open a ticket for someone else, they can unlock it.
In any case, those who use this feature are usually technicians in forms, apart from opening tickets by the user. If we base it on version 10, the scenario would be a question within the GLPI object type form > users.
My suggestion is to keep it as it is in version 10. Thank you for your attention.
I want to clarify, this is not just about being in a group, this is about being a "delegatee" in a group.
As far as I known, this is the only use case of being a "delegatee" in a group, so if you do not want the feature I think you should remove all your delegatees as they don't serve another purpose anyway.
I understand that if you used formcreator before it might seem normal to remove this feature to be coherent but we also have many users that never used formcreator and expect the opposite and would complain if it is missing.
I think there are no others alternative that to review your groups and remove the delegatees.
@AdrienClairembault I understand, thank you for your response. Actually, it was good to clarify this function for me, because I didn't understand the explanation anywhere else or on any forum. Now I understand that delegating means opening a ticket for another user, correct? And not including them doesn't affect the profile/service part, right?
Now I understand that delegating means opening a ticket for another user, correct
This is correct, delegating means opening a ticket for someone else.
And not including them doesn't affect the profile/service part, right
It should not :)
@AdrienClairembault Hi, in my opinion, this feature has changed in the new version 11. In the tests I did on glpi 10, even after unchecking the delegate option for groups, I can still open tickets for other users in the assistance view > tickets. But assuming that in version 11 it will be as you said, then that's fine. Thanks for reporting this.