Choose who can see it and Task closed box timer display

[Multiconecta]

@OscarBeiro , @xacobofg , @boscorelly (and whoever wishes to colaborate), I'd like to hear from you about these two suggestions that seemed really neat:

I have it published at my branch dev_timer_for_others.

There are, actually two different commits with two different options (as there is config database table change, I include both at once, but can be separated, of course):

1. Choose who can see the tasks' timers. Currently with two options:
   a. Only the task user (as is the original idea)
   b. All users, so supervisors, customer could also see it (my suggestion, as my customers need to confirm work hours)

• Of course this is an idea, other filters can be applied, like "Task's group members", "Ticket assigned users/group member", "Ticket requesters", "Ticket watchers" (I think that would be easy to be implemented). Another way to go would be to create rights that could be somehow - I am not a Glpi expert (yet) ;) - be assigner to profiles, to see timers, statistics, reports etc. (1.3.0?)

2. Show timers (actual total time) in the tasks' boxes in the Action historical list (Processing ticket tab) when the boxes are closed. Next to the status checkboxes each task's timer is shown (to whomever is allowed to see the timers). For the task user, the running timer will be shown also, making it easier to find which task has its timer running (other than clicking on pop-up timer).

• This is also a plugin setting, so you can disable it (today, the default would be enabled, because I really liked it :D, but the default could also be the current disabled).

[OscarBeiro]

Hi,
Our original project concept was an internal management time tool. It is OK to enhance if it is possible to keep the idea with the default settings.

So here are my suggestion:

1. Two options, using interface as a condition:

• Central - Will show all timers to all techs
• Helpdesk - Will show all timers to every other user.
  As you suggested, it could be added a more detailed configuration, but right now seems overkill.

2. It is OK as long as the same conditions are met as for the previous suggestion. I wouldn't have done your additional setting to show it when closed, but since it's already made I would keep it.

Thanks

[Multiconecta]

Our original project concept was an internal management time tool. It is OK to enhance if it is possible to keep the idea with the default settings.

Hi. First of all, sorry for overwhelming with so many ideas and PRs. Is that your project is so great and helpful it is our main plugin. People are new to Glpi, so ideas keep coming.

So here are my suggestion:

1. Two options, using interface as a condition:

• Central - Will show all timers to all techs
• Helpdesk - Will show all timers to every other user.

That means remove the setting "display only for task tech" and "display to all users" and make that distinction on the interface used, right? If interface is Central, only techs get to see the timers. But how can I determine who are the techs?

Currently, the timers are only shown for the User that is that specific Task technician. This is the expected behavior in Central interface? I'll try to make it that way.

About the overkill, I'll look int glpi rights to see if the implementation would be simple. I think only two would do it:

• Use timers in your tasks: Yes (default), No
• See timers: Only in owned task (default), None, All
  That way, we could use profiles and some people could be restrict to an entity or restrict the timer only for techs, for example. For big implementations, or multi entity environment, it can be useful. In the future, would be possible to extend the view rights for requesters, watchers and assignees.

[Multiconecta]

2. It is OK as long as the same conditions are met as for the previous suggestion. I wouldn't have done your additional setting to show it when closed, but since it's already made I would keep it.

I know. At night I couldn't sleep, so I tried and I liked. 😃

[OscarBeiro]

No worries. There's no such thing as too many ideas. :)
The thing is to keep them sorted to deal with them easily.
Right now, I feel we are discussing quite the same in two different issues.

So back to work:

If a profile is using Standard Interface (Central), we will consider this a tech. It might not be the case if you reduce their permissions, but it's the simplest way to draw a line. so:

• Central (Standard interface): Company (or support)
• Helpdesk (Simplified interface): Clients (or supported).

Following the same reasoning, for see timers I would now choose this two options:

• Techs only (or whatever other name you choose): Only Central (Standard interface): Company (or support). In-company or support workers are the only ones to see the counters (which was the desired behavior from the begining)
• All users: Even Helpdesk (Simplified interface): Clients (or supported). Which is the behavior your company is apparently looking for.
  Of course, this is a slight change, but uses de KISS principle.

As for the Use timers in your task, it is OK to keep it, but why should you disable them? If you do it, then you do not need the plugin :)

[OscarBeiro]

Currently, the timers are only shown for the User that is that specific Task technician. This is the expected behavior in Central interface? I'll try to make it that way.

This seems to be the only way.
You wouldn't want another user to start, pause or stop your timer.
And now here you have the explanation for the other question you made in #4

GLPI user creates the task, and it is assigned to TICgal GLPI Support.

1. In this screen shot active user is glpi. He created the ticket, he can see the timers, but he cannot see the buttons
   
   2.Same ticket task with TICgal GLPI Support user. He can see the timers and the buttoms, because he is the tech assigned to the task.
   

In the case you mention in #4, your hotliners are creating the tasks and of course GLPI is self assigning them, but they should change who is the tech, or tech group dealing with them.

IMO, this has nothing to do with GLPI or this plugin but with how you manage your ticketing workflow.

Please let me know if it is clear now.

[Multiconecta]

This seems to be the only way.
You wouldn't want another user to start, pause or stop your timer.

1. In this screen shot active user is glpi. He created the ticket, he can see the timers, but he cannot see the buttons

Yes, I can understand that very clearly and agree entirely. What I've pointed out as a bug was this very specific situation:

• hotlineruser has CREATE TASK right, but does not have UPDATE TAKS right. He/she, then, creates the task and keep him/herself as the task user (Glpi default).

In that situation, Glpi permits that hotlineruser opens the task edit form, but there is no SAVE button. That means, he/she CANNOT edit any field in the task form (he/she could do it before clicking Add button, but no more, after actually creating the task). This Glpi default behavior, seems, to me, very OK.

Then, here comes the Actualtime Plugin situation: if the TASK UPDATE right is not checked when opening the task form, we will always show the timer's Start/End buttons, even if the task user does not have rights to update the task (Glpi checks it and only provides the Save button if the right exists). This would create and odd situation. If the user starts and then click the End timer button, he/she would actually change the task status, even if he/she does not have the right to do that!

IMO, everything should remains exactly the same, but we should just check if the user has the task update right before showing him/her the buttons (of course, only the task user will have buttons, but being the task user would not be sufficient as he/she should also have task update right). That would also solve the situation where @boscorelly suggested of a user that CAN open task but CANNOT start timer (as he/she should never be assigned to the task).

This would be just an additional AND clause in an existent IF (it is on issue #4 sent PR #36 on this commit:

-                $buttons = self::checkTech($task_id);
+               $buttons = (self::checkTech($task_id) && $item->can($task_id, UPDATE));

Please let me know if this check should be kept.

[Multiconecta]

Back to this specific issue:

Following the same reasoning, for see timers I would now choose this two options:

• Techs only (or whatever other name you choose): Only Central (Standard interface): Company (or support). In-company or support workers are the only ones to see the counters (which was the desired behavior from the begining)
• All users: Even Helpdesk (Simplified interface): Clients (or supported). Which is the behavior your company is apparently looking for.
  Of course, this is a slight change, but uses de KISS principle.

As for the Use timers in your task, it is OK to keep it, but why should you disable them? If you do it, then you do not need the plugin :)

Maybe a even better tuning:

1. Remove the first setting (Enable timer: Yes or No). This is already acomplished enabling or disabling the plugin it self, in Setup - Plugins. This setting was there so we could enable the settings page, without actually having any useful setting.
2. Replace it with with a really more meaningful one:

• Enable task timer:
  • In Standard interface only (default)
  • Both in Standard and Helpdesk interfaces
  • In Helpdesk interface only (it seems not making too much sense, using your analysis, and should not exist, although, in this scenario, does not involves any additional coding)
  • Never (disable task timers) (the same, as explained above, that would be just disable the pluging, so, maybe a redundant setting option)

I think that would meet all our requirements. The third and fourth options are there only because they would be very simple to implement (all the checks are already done), but are obviously optional.

[OscarBeiro]

Maybe a even better tuning:

1. Remove the first setting (Enable timer: Yes or No). This is already acomplished enabling or disabling the plugin it self, in Setup - Plugins. This setting was there so we could enable the settings page, without actually having any useful setting.

Agreed

2. Replace it with with a really more meaningful one:

• Enable task timer:

  • In Standard interface only (default)
  • Both in Standard and Helpdesk interfaces
  • In Helpdesk interface only (it seems not making too much sense, using your analysis, and should not exist, although, in this scenario, does not involves any additional coding)
  • Never (disable task timers) (the same, as explained above, that would be just disable the pluging, so, maybe a redundant setting option)

I think that would meet all our requirements. The third and fourth options are there only because they would be very simple to implement (all the checks are already done), but are obviously optional.

Agreed, options 3 and 4 don't add any interesting feature and could create a mess on an incorrect setup.

Thanks.

[OscarBeiro]

Yes, I can understand that very clearly and agree entirely. What I've pointed out as a bug was this very specific situation:

• hotlineruser has CREATE TASK right, but does not have UPDATE TAKS right. He/she, then, creates the task and keep him/herself as the task user (Glpi default).

IMO, this is a ticket task creation bad practice. Maybe using a task template could help your organization.

Said that, I understand you need to solve this particular problem, and your fix won't affect expected behavior of the plugin. Go ahead and make a PR.
Please document link it to this issue, so we can review it in the future.

Thanks again for your great contributions

[Multiconecta]

IMO, this is a ticket task creation bad practice. Maybe using a task template could help your organization.

I mine too. But this situation now is possible in Glpi, so I think we should comply with it. Anyway, this particular "feature" is already solved in PR #36 (that solves Issue #4).

I will send a new PR for this issue.

[Multiconecta]

Said that, I understand you need to solve this particular problem, and your fix won't affect expected behavior of the plugin. Go ahead and make a PR.

Made. #38

[OscarBeiro]

Obrigado de novo :)