glpi-project/glpi

Log from which position a user is removed

Opened this issue · 9 comments

Code of Conduct

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

Contribution description

When adding a requester, observer and technician assignments in a ticket, the position the user is assigned to is logged. But when removing a user from a position the position is not logged.
Combined with the fact that users are added first the log the appears to be in the wrong order.
I would like adding the position the user is removed from to the log

When opening an issue; please use template and fill all requested information; thank you.

This issue has been closed because you did not provide the requested information.

@trasher I used the template for contribution request ? As I would not consider it a bug more of an improvement I'm willing to contribute if the glpi team is interested / considers it useful. Was this the wrong approach?

Oh... I did not understand this was a feature proposal you plan to work on. Sorry, I reopen.

I can't say if that change is or not interesting, I'll let someone else take a look.

I would like adding the position the user is removed from to the log

Please yes, you can submit a PR for that.

Hi,
this was a bit harder then I thought 😅 so it took a while, but now I have a working solution.
Would you like the pull request against the 11.0/bugfix branch against the 10.0/bugfix or against the main branch?
Or can I provide a version for 11 and 10? If possible I would really like to have this in 10 as well.

One other thing I noticed is the implementation for post_addItem is missing in Problem_User.php. Is there a specific reason for this ?
Maybe the implementation should be done in CommonITILActor instead of the subclasses ?
Would you like me to:
a) Only fix ticket history as originally proposed and open separate requests for the other changes
b) Add the feature to all relevant subclasses and add the missing method to Problem_User subclass
c) Implement it in CommonITILActor
I feel option c might be the cleanest, but of course you have much more experience and maybe there is a reason to do it in the subclasses I'm missing.

Hi, this was a bit harder then I thought 😅 so it took a while, but now I have a working solution. Would you like the pull request against the 11.0/bugfix branch against the 10.0/bugfix or against the main branch? Or can I provide a version for 11 and 10? If possible I would really like to have this in 10 as well.

No new feature will be accepted for GLPI v10.
You can target v11 I think, it will not be a big deal to change to main if needed.

One other thing I noticed is the implementation for post_addItem is missing in Problem_User.php. Is there a specific reason for this ? Maybe the implementation should be done in CommonITILActor instead of the subclasses ? Would you like me to: a) Only fix ticket history as originally proposed and open separate requests for the other changes b) Add the feature to all relevant subclasses and add the missing method to Problem_User subclass c) Implement it in CommonITILActor I feel option c might be the cleanest, but of course you have much more experience and maybe there is a reason to do it in the subclasses I'm missing.

I'm not sure I understand. A post_addItem method does exists in CommonITILActor, and Problem_User extends it.

No new feature will be accepted for GLPI v10.
You can target v11 I think, it will not be a big deal to change to main if needed.

Ok.

I'm not sure I understand. A post_addItem method does exists in CommonITILActor, and Problem_User extends it.

Adding the position in the log is done by overriding the post_addItem method from CommonITILActor. For example in Ticket_User or in Group_Ticket . In Problem_user this override is missing. So in contrast to a Ticket the position someone is assigned to is missing in the problem log. The code needed would be exactly the same as in Ticket_User. Is it ok to just duplicate it ?

I do not know well this part, but code should not be duplicated if it can be avoid. Most of the time, common parent class/trait is the best place.