GNOME Bugzilla – Bug 435939
work duration converted to "work days" assumes fixed day length
Last modified: 2021-06-09 20:38:38 UTC
Please describe the problem: If more than one day type contains work hours and the number of hours is different, the conversion from time to work-days is incorrect. I.e. if I include some hours on a weekend. Steps to reproduce: 1. Change work hours for non-working day type to include i.e. 14 hours 8:00 - 22:00 2. Change work hours for working day type to include i.e. 4 hours 18:00 - 22:00 3. Create a new task that will span the weekend Actual results: When the work time (and duration) is entered, it is converted to work-days based on the number of seconds of work in the "work" day type. If the task spans a weekend, it calculates the number of seconds in the weekend day as the same as a "work" day (i.e. 4 hours by in this case). If the task starts on friday and I enter 3 days for the work time, it calculates this as 12 hours, displays 3d, and puts the end in the middle of saturday. If I enter 32 hours for the work time, it displays 8d and puts the end at the end of sunday (where I want it). If I then change the start day to monday, it keeps the 8d duration which puts the end at saturday (not what I want). Expected results: I don't think work time and duration time should be converted to work-days. If there is more than one type of work-day, then even if the calculation is correct when it is done, if the task start time shifts due to predecessors, it will not be able to re-calculate the correct time. Durations should be kept as seconds from start to completion. The conversion to start day/time and end day/time should be done for the task and gantt windows, but should not affect the user input data. Does this happen every time? Yes Other information: It looks like the problem starts in planner_parse_duration and planner_format_duration in planner-format.c. Both functions call mrp_calendar_get_day_total_work() with mrp_day_get_work() to figure out how many seconds of work in a day. It should at least call mrp_calendar_get_day_total_work with the correct day type, but as I say above, I don't think this alone will work because as the start time of the task shifts, this calculation would need to be redone using the originally entered work time.
I have a problem which I think is related, but the bug I found is rather related to the GUI representation in the Gantt chart: I am using planner 0.14.4, windows installation. When I want a task to be started or extend over a weekend, I ensure that the related resource calendar has 'working' days during the weekend and I set the fixed start date. This successfully creates the gui rectangle showing the timespan. However the blue/grey colouring is random and changes sometimes for no reason (or perhaps I hovered over something). Often the fill colour starts after the weekend and almost always extends past the timespan. When I hover over the resource link (after the time span), often the colouring extends out to the end of the text. But it's really random and also hovering over other gui elements causes changes. Note that I have a default calendar with weekends 'non-working' and I have copies for individual resources with individual weekends that they work changed to 'working'. The bug is only relevant for weekends that have been changed to working. Tasks that span weekends that are non-working are fine. I also have a calendar that has all working weekends and no holidays either. This works fine also. I have also changed the working hours for all standard calendars to 00:00 to 23:59 such that the time spans actually span complete days. Kind of a work-around to ensure readability of the chart (I only work in days for tasks). Perhaps this has caused an incongruity.
I just had another look. It looks like it happens for any task that starts on a weekend day if it has been set as working. Somehow the weekend (sat / sun) days are being recognised as weekend days even though I have made them working. Might make it difficult for people in islamic countries to use planner :-)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/World/planner/-/issues/134.