Actions
Task #3266
closedTask #3262: Improve the way scheduled tasks are presented
Scheduler tasks - sort by trigger start time
Start date:
03/06/2023
Due date:
% Done:
100%
Estimated time:
24.00 h
Owner:
Description
Allow to sort scheduled tasks by trigger start time
Files
Updated by Boris Polák almost 2 years ago
- Status changed from New to In Progress
Updated by Tomáš Doischer almost 2 years ago
- Sprint set to Sprint 13.1-2 (bře 08 - bře 22)
- Estimated time set to 24.00 h
Updated by Tomáš Doischer almost 2 years ago
- Sprint changed from Sprint 13.1-2 (bře 08 - bře 22) to Sprint 13.1-3 (bře 22 - dub 05)
Updated by Jan Potočiar over 1 year ago
- File response.json response.json added
- Status changed from In Progress to Needs feedback
- Assignee changed from Jan Potočiar to Peter Štrunc
- % Done changed from 50 to 80
Introduced new endpoint: /upcoming-tasks
It is very similar to /scheduler/tasks with few differences:
It is very similar to /scheduler/tasks with few differences:
- Only tasks with defined nextFireTime are listed
- consequence: tasks without triggers or only dependent triggers are not listed (in the main list of tasks)
- New field introduced to each task: dependentTasks
- this new field contains list of tasks that are dependent on the task
- list of next fire times, limited by time (seconds from now) or count (total size)
- whichever limit is lower will apply
- nextFireTimesLimitCount default value is 1
- nextFireTimesLimitSeconds default value is 1 day
- the main list only contains tasks with Cron or simple trigger (consequence of 1))
- each task contained in the main list is there only once (even when it is executed more than 1 time)
- the information about multiple times of executions is in the triggers of the task
- It is not possible to say something like "I want all tasks that will be executed in next 24 hours"
- the main list of tasks itself is unlimited - should I implement something like this?
- it is only possible to limit cron triggers like that
- Since cron triggers received new field nextFireTimes which also contains nextFireTime as its first value, the field nextFireTime is redundant from the data perspective in most cases
- I kept the field in there because it is used in a different way than nextFireTimes
- The workaround would be too complicated if we wanted to get rid of the data redundancy IMO
- I kept the field in there because it is used in a different way than nextFireTimes
Example response -> https://redmine.czechidm.com/attachments/download/1212
PR: https://github.com/bcvsolutions/CzechIdMng/pull/362
Updated by Tomáš Doischer over 1 year ago
- Sprint changed from Sprint 13.1-3 (bře 22 - dub 05) to Sprint 13.1-4 (dub 05 - dub 19)
Updated by Peter Štrunc over 1 year ago
- Status changed from Needs feedback to Resolved
- Assignee changed from Peter Štrunc to Jan Potočiar
- % Done changed from 80 to 100
PR merged. Thanks
Actions