Closed rejkid closed 1 year ago
Really annoying. This was discussed extensively in #8. I told that avoiding tasks with the same name but allowing tasks with a different name was outlandishly complex. Now you want to take all that out!
The issue management process is straightforward and varies only little depending on circumstances. You will find the same process is followed all over the world where reliable software is developed.
That's OK. I was just wondering if you are willing to implement that?
Well, then you should have asked that.
I am busy working on #19. Bugs always get a higher priority than anything else, but especially compared to features that have changed so many times that n0-one can remember what was originally requested.
Should I raise the new issue?
There is nothing wrong with this one.
I mean can you implement the algorithm the way I described in my comment that you deleted.
Of course I can! As the title of this issue says, all I have to do is undo the work I did for you last week.
First you told me that the timeslots where independent, then you told me that assignments blocked only assignments to the same task type, now you tell me that assignments to all task types are blocked.
So my question is, how many more changes to this feature will there be? I am reluctant to work on this any more until I am confident you actually know what it is you require.
Here is the agent attribute that enables blocking per task type
If task type blocking is removed, than all we need is to store the last assignment time. The vector of timepoint, task type pairs can be replaced by a single timepoint from the last assignment ( of any task type )
timepoint_t myLastAssignmentTime;
Here is the method that determines if an assignment is blocked on a task type basis
This becomes unnecessary and can be replaced with a single line
if (std::chrono::duration_cast<std::chrono::hours>(timepoint(day) - myLastAssignmentTime).count() > hours_blocked)
return false;
I am ready to implement this as soon as you confirm your requirement by assigning this issue to me.
Before we start, let me go back to the people I am doing that for to give me some more clarification. They also mentioned that it would be a really good feature to assign agents from the same family (new concept) to the same time slot (so the family can be together doing their task). I initially said that it is impossible for the algorithm to be aware of agents of the same family, but I thought I would consult that with you before I tell them definite answer.
Format sounds good.
The client is happy with: "Assigning Agent A to a task with the name T prevents her from being assigned to any other task for today and tomorrow"
Repeated test for issue #23
The test in #23 does not test this feature. That test has only one task type. This feature is intended to block assignment to other task types instead of blocking just the same type as you originally specified.
Input: a alice 1 smith teacher cleaner t 202311010830 teacher cleaner t 202311020830 teacher cleaner
Output: A 202311010830 alice to teacher
1) The result proves that alice can be assigned to teacher for time slot 202311010830 2) The result also proves that alice can't be assigned to cleaner or teacher for time slot 202311020830 as she is already assigned to teacher task for time slot 202311010830. With the previous implementation alice would have been eligible for an assignment to cleaner next day (202311020830)
Good test report.
Thank you
Sorry James, my mistake (ahhh) Could we change "Assigning Agent A to a task with the name T prevents her from being assigned to any other task named T for today and tomorrow" to "Assigning Agent A to a task with the name T prevents her from being assigned to any other task for today and tomorrow"