request : use the plugin when creating a task

[boscorelly]

Is it possible to enable the usage of the plugin when creating a task ?

it will be helpful for us.

[OscarBeiro]

Hi,
Thank you for your suggestion.
We think it's not very useful, and can create issues.

If a task is not saved, and you start a timer nothing is saved in the DB. So if you close the browser window, everything is lost.
With current behavior, Once you start the timer, it will continue tracking time , no matter what, until task is checked as Done, or timer is stopped.

Regards

[boscorelly]

i understand, but as e don't use glpi to sched tasks, it's not so usefull for us :(

i was thinking the plugin was acting as a chronometer as lawyers use :(

[OscarBeiro]

It does. You need to :

1. Create a task with status To Do and save.
2. Edit the task and start the timer
3. Make the task, and some comments if you want and stop the timer.

Repeat as many times as you need.

I hope it fits you, If you need any other behavior we could talk about it.

[boscorelly]

We just need to be able to have it before creating the task :)

[OscarBeiro]

We could discuss a solution.
If you wish to fund it, please contact us through our website.

[boscorelly]

what ?!

[Multiconecta]

Maybe the start button could be shown on task create form and perform an 'Add' action followed immediately with the 'Start' action. I'll look into the code if that is possible.
Or else, find a way to open task edit box as soon the task is saved with the 'Add' button. I am not sure if there is a hook to do exactly that. As this enhancement would also help me greatly, I will try to find a safe solution, without disrupting the developers' original idea.

[Multiconecta]

Ok. I've got a working test for this specific feature: when a new task is created, it is automatically opened. So all you have to do is click on "Task (create)", click on "Add" and automatically the task list is loaded and the newly created task is opened. Just click "Start" and the timer is on (no need to click on "Edit Task" before). This will not disrupt anything on ticket or ActualTime procedures.

The only detail is: I use glpi_plugin_actualtime_task database table and create a record with the tasks_id and "zero" as the users_id. Using the database was the easiest way I found for from Item Add Hook tell Post Show Item Hook to open the task edit box. I know this field was not supposed to do that, but we would have to come up with some different solution.

[Multiconecta]

Another thought:
a) adding a task automatically starts the timer (that could be automatically, manually chosen by a checkbox or globally configured in a new plugin global settings.
b) automatically opening the task edit box for the task currently having the active timer. That's not a bad idea at all, as sometimes you can have many created tasks (10, for example) and the technician started the timer on task 5. Listing the tasks will bring a pop up message stating you have a time started on this ticket, but you cannot know which task. If the edit box for the active timer (for the current user) always opened by default, it would be easy to find out which.

If OscarBeiro is Ok, I can work on modifications that includes (a), (b) and also:
(c) plugin global settings with the following automatic behavior settings:

• automatically open the new added task
• automatically open active timer task
• automatically starts timer for the new added task

I would like boscorelly's input, if possible.

[OscarBeiro]

Hi Multiconecta,
Thank you for your time.
I like the idea of global settings. Not losing its main functionality, while adding features is the way to go.

The thing here is you're talking about a few changes, so we would like to split each new feature into a different Issue and its PR.

Is that OK?

Obrigado

[boscorelly]

i think if i can test, i'll be able to tell if it's good for us :)

[Multiconecta]

Hi Multiconecta,
Thank you for your time.
I like the idea of global settings. Not losing its main functionality, while adding features is the way to go.

The thing here is you're talking about a few changes, so we would like to split each new feature into a different Issue and its PR.

Is that OK?

Obrigado

Perfect. That seems the way to go.

[Multiconecta]

@boscorelly , you can try to see if that's what you were thinking at this branch. I was thinking the possibility of a checkbox when including the task (not sure if there is a hook for that) where I could start the timer when the task is created (when it is created, the form will open with the timer on). But I am not sure if this is really useful, as if you create the task, the form will open and you can immediately, manually, click the 'Begin' button.

EDIT: corrected some coding standard and also you can set to have the task window automatically opened if there is a timer running for that task (and logged in user).

[boscorelly]

Hi,

with your update, i don't have the timer starting without creating the task.

[boscorelly]

I created a task, started a timer, tried to pause it : "Seul l'utilisateur qui a démarré la tâche peut l'arrêter" (only the user who started the task can stop it)

[Multiconecta]

Ok. So you did the update, correct? (plugin version should report 1.1.3, so the database is updated). If you did that, now you have the pause button (issue #17 ). To have auto open window (when a new task is created or when the timer is on), you must change the settings to do so (if you don't change the settings, the behaviour does not change). Go to 'Configuration' - Générale - Actual time and turn on the needed settings.

[Multiconecta]

Hi,
with your update, i don't have the timer starting without creating the task.

Well, it will not start without create the task (I think I mentioned that above). Before you click 'Add' (Ajouter) in task creation windows, the task does not exist in the database, and does not have an ID. So it is impossible to start a timer for that task. What we created was a way to, just after you click 'Add', the task window reopens automatically and, then, you can click on Begin/Início/Début and start the timer.

That was the best thing I could imagine to fulfill our needs (my company also needed to start the timer right in the moment the task is created. The best option was click the 'Tâche' button to create a task, then, immediately, 'Ajouter'. The task is created in the database and the edit window is automatically opened. There you can start the timer and fill any field needed.

[Multiconecta]

I created a task, started a timer, tried to pause it : "Seul l'utilisateur qui a démarré la tâche peut l'arrêter" (only the user who started the task can stop it)

Well, Camille, that's really odd. It is the same issue #5 you created before. I'll try to look into it. I think Oscar found that the task timer was created with an user ID that does not exist. It really does not make too much sense, as the ID is picked from the user currently logged in, using Glpi's core session function, to create the timer. To stop it, the same session function is used to verify if the stopper is the same as the starter. When you create the task, the same user logged in is the user in 'Utilisateur' field, the same user that starts the timer and the same user that tries to stop it?

[boscorelly]

yes it is :(

select id, name from glpi_users where name = 'coe';
+-----+------+
| id | name |
+-----+------+
| 153 | coe |
+-----+------+`

select * from glpi_plugin_actualtime_tasks;
+----+----------+---------------------+---------------------+----------+-------------------+
| id | tasks_id | actual_begin | actual_end | users_id | actual_actiontime |
+----+----------+---------------------+---------------------+----------+-------------------+
| 1 | 23543 | 2019-01-24 09:55:40 | NULL | 127 | 0 |
| 2 | 23815 | 2019-03-04 12:12:19 | 2019-03-04 17:16:44 | 127 | 18265 |
+----+----------+---------------------+---------------------+----------+-------------------+

select id, name from glpi_users where id = '153';
+-----+------+
| id | name |
+-----+------+
| 153 | coe |
+-----+------+

select id, name from glpi_users where id = '127';
Empty set (0.00 sec)

[Multiconecta]

| 2 | 23815 | 2019-03-04 12:12:19 | 2019-03-04 17:16:44 | 127 | 18265 |

Well, that's odd. But there's something else odd: the timer id 2 is closed for tickettask id 23815. It was started the day before yesterday, at 12:12 and was successfully stopped the same day, at 17:16. The task user is really id 127, and the calculated active time was 18,265 s, or 5h 4min 25s.

So, even with the error message was you able to stop the timer?

The same does not apply to the timer id 1, that seems to be still running since January. Maybe there is no more the tickettask. And there goes another oddity: user id 127 should no be able to start a new timer on March 4th, as there's already a timer running for that user started on January 24th.

I'm trying to replicate that here, with no success.

I'll look into Glpi ticket tasks' core code better to try to understand how user id 153 starts a timer as inexistant user id 127.

If there's no sensible information, could you please send the output of the task and ticket info?

SELECT glpi_tickets., glpi_tickettasks. FROM glpi_tickettasks LEFT JOIN glpi_tickets ON glpi_tickettasks.tickets_id = glpi_tickets.id WHERE glpi_tickettasks.id = 23815 OR glpi_tickettasks.id = 23543;

[boscorelly]

Hi,

it may have been closed because i closed the ticket ?

[Multiconecta]

Well, it seems you have found the problem of #5 . Can you test the automatically opening of task edit windows when you create a new task, @boscorelly ? Would it solve your issue that way?

[Multiconecta]

it may have been closed because i closed the ticket ?

Yes. The pre-update hook do stop the timer when you close a ticket.

[Multiconecta]

Camille, I made some adjusts on the code, including all current commits already in 'development'. Please, now that you fixed the user id problem, could you try the "Auto open new tasks" feature to see if this way solve your need.

Clone my branch dev_autoopennewtask or download/extract the alpha release in directory plugins/actualtime/. Good idea to move current actualtime directory to a backup place, so you can return to current version after tests concluding. I didn't have problem with my current data (unless you click in Uninstall in plugins page, when you loose all your timers data!!!) But not using in a production environment is advisable.

Install: the version is changed to 1.1.4, to force a database update (four new settings are available in this test version):

1. Go to Setup - Plugin, click on Upgrade, then Enable
2. Click on Actuatime (the plugin name), or Setup - General - Actualtime tab.
3. Change the setting Automatically open new created tasks to Yes.

Once again, you cannot start a timer before the task is saved (the first time), because it must exist (the timer is linked to the task id). So that's the steps your user must do:

1. In Ticket's Processing ticket tab, click Task to create a new task.
2. In the form New item - Ticket task, fill whatever you need (or nothing at all)
3. Click Save
   (the new task is created, the page will be reloaded and the just created task form will automatically open and scroll to the top of the window)
4. That moment, you can just click Start and the timer is on.
   (may seem a lot here, but that's just 3 clicks)

[Multiconecta]

New features in this test version:

1. Timer pop-up is fixed (opens on any page you navigate, opens only once, has the exact same time as the task form timer, no bug dragging the pop-up window). Already in development branch
2. Enable/disable the timer pop-up window (that opens when there is an active timer for current user). Can be disabled/enabled in the plugin settings page.Already in development branch
3. Clicking on the pop-up window, opens a modal dialog with the current active timer task form, so you can verify/edit task data and also stop the timer. Already in development branch
4. Pause/Restart button, so timer can be stopped without marking task as "Done" (you no more need to change status back to "To do", close and reopen the task form to be able to restart a timer after a coffee break, for example). Already in development branch
5. Choose who can see the actualtime times (only "task user" or "any user"). Must choose in the plugin settings page.
6. Show the total time and current running timer in the task lists, on the task boxes (without opening the task form). Must enable in the plugin settings page.
7. Automatically open the task form for new tasks, when you press Save, so you can immediately start the timer and/or include more data in the task form. Must enable this behavior in the plugin settings page.
8. Automatically open the task form when you enter on the tasks list (Processing ticket tab) if the timer is on (running). The task with the running timer will open and the list will scroll it to the top of the window, every time you enter the tasks page (if option 7 above is enabled, when you create a new task, both forms will be automatically open, the window will scroll to the newly opened task). Must enable this behavior in the plugin settings page.

[boscorelly]

Hi,

i'll try this.

For point 7, can you do this with a user or group ? We want that only technicians can see it but not customer or phone answers.

[OscarBeiro]

Could you please push 7 and 8 to development?
I have answerd 5 and 6 on #35
Thanks

[Multiconecta]

For point 7, can you do this with a user or group ? We want that only technicians can see it but not customer or phone answers.

Hi, I didn't get that one very well. Your customer or phone answers can add tasks, but you'd like them to be unable to start a timer? I imagine you use profiles for that. The default Self-Service will not allow you to create tasks, so, no timer buttons:

The customer cannot open a new task (so 7 does not apply). When viewing the tasks, the customer cannot open or edit it, so, no timer buttons also.

[Multiconecta]

On the other had, I used a new user as phone answer, with Hotliner profile modified so the user can create a task, but cannot update it. This way, you really found a bug both in plugin and also in Glpi:

• In Glpi, a user that cannot update a task (but can create it) should not be allowed to be chosen as Task User when creating it. No one can assign that user as task user, but if the user is the task creator, it will be created by default with that creator as the task user.
• In the plugin, for that uncommon situation. it should verify if the user has update rights on the task (that verification is important, but wouldn't be necessary if Glpi refused to assign as task user someone without task update rights.

This is related to item 5, and it is being discussed in issue #35 . I think the best way to address it would be using profile rights. To circumvent the Glpi bug, it would be good to check if user has right to update task (we could do when verifying if the user is the task user, so nothing more is changed).

[Multiconecta]

Could you please push 7 and 8 to development?
Thanks

Done. Bug above corrected also (buttons will only appear if user actually has rights to update the task).

@boscorelly , in the future we may try to develop an arrangement where we could specifically set rights for task creator, task technician, task group, and ticket watchers, ticket requesters and ticket assignees. One could set those rights in different profiles and assign those profiles to different users and entities. That way one could have granular definition of who can use the timer and also who can see the timers. But that's a new issue. Today we will be able to set who can operate granting or revoking profile's right to update tasks. So, if you have update task, you can be assigned to a task. Also you can start and stop the timer in the tasks you are assigned to.

[Multiconecta]

Could you please push 7 and 8 to development?

Done in PR #36

[xacobofg]

Merge PR #36 but not work when I merge PR #38.
I don't understand what is the difference between these two options

[Multiconecta]

Well that mess in on me. We should be working in one at each time, as they changed the same functions. We've got some collisions in code merging. Doing a PR right now to solve all these (error on creating database table, method exiting too soon because of double break command, error formatting settings page.

I don't understand what is the difference between these two options

About those, they address different user suggestions:

• Auto opening for new tasks will solve this current issue (request : use the plugin when creating a task #4), as it will be possible to create a task and immediately open the task edit form, so the tech (when the tech creates his/her tasks by him/herself) can push the timer Start button. (@boscorelly )
• Auto opening running timer tasks would help for techs that enters their tickets and goes directly to their current running task. A shortcut. Of course they could just click on timer popup and open a modal window, but, sometimes they need to go to ticket page, so they can see other related info (ticket items, ticket documents etc.). (me)

Both options default to DISABLED, and are just a plus for custom behavior some user may prefer.

[Multiconecta]

Well that mess in on me. We should be working in one at each time, as they changed the same functions. We've got some collisions in code merging. Doing a PR right now to solve all these (error on creating database table, method exiting too soon because of double break command, error formatting settings page).

PR #39 will do it. Tested (I think) all possible configurations and situations.

[OscarBeiro]

Thanks again.