https://community.openproject.org/wp/58011
This makes it possible to have a follower starting the same day a
predecessor ends, or at the same time as a predecessor starts.
Updated allowed lag range to be within -2000 to 2000 days.
Co-authored-by: Alexander Brandon Coles <a.coles@openproject.com>
https://community.openproject.org/wp/62891
For an automatically scheduled successor, when "Working days only" is
turned off and the day before the start date is a non-working day, the
start will shift to an earlier date. Multiple things need to work
correctly:
- The start date must be recalculated and displayed in the date picker.
- The mini calendar of the date picker need to have enabled dates
updated, as the start date has changed.
- If the due date was not set manually, duration must be kept and due
date will be recalculated.
- If the due date was set manually, it must not be changed and duration
will be recalculated.
- If the due date was unset manually, it must remain unset and duration
must be unset too.
Also the lag calculation was partly incorrect: it was adding non-working
days when "Working days only" was on, and days when "Working days only"
was off. This has been fixed: lag is always about working days
regardless of the successor "Working days only" setting.
https://community.openproject.org/wp/63152
When the browser timezone offset is negative, the enabled dates in the
date picker for an automatically scheduled successor were not correct:
the date before the start date was enabled.
This is now fixed.
The `schedule_manually` column is also non-nullable now.
This includes the following changes:
- Automatically scheduled parent dates are and `ignore_non_working_days`
attributes are now always derived from children's values, even if the
children are scheduled manually.
It's more natural. Without that, adding a child to a work package
would not change the parent's dates.
As a consequence, the parent can start on a non-working day if one of
its children is manually scheduled, ignores non-working days, and
starts on a non-working day. That's why the parent's
`ignore_non_working_days` attribute is now also derived from all its
children regardless of the scheduling mode.
If the parent is manually scheduled, its dates and it's ability to
ignore non-working days will still be defined independently from its
children.
- Fix tests broken by scheduling mode being manual by default.
The tests had to be adapted to explicitly set scheduling mode to
automatic for followers and parents, and sometimes even follower's
children. Without it, work packages would not be rescheduled
automatically.
- Replace schedule helpers with table helpers.
Schedule helpers helped well, but table helpers are more flexible and
support more column types.
- Add "days counting" and "scheduling mode" columns to table helpers.
"days counting" to set `ignore_non_working_days` attribute.
- "all days" value maps to `ignore_non_working_days: true`.
- "working days" value maps to `ignore_non_working_days: false`.
"scheduling mode" to set `schedule_manually` attribute.
- "manual" value maps to `schedule_manually: true`.
- "automatic" value maps to `schedule_manually: false`.
When a follows relation has a delay, and this delay covers some
non-working days, the soonest start date must be computed by having the
delay spanning only on working days, not on non-working days.
* Fix argument alignment since f08bea3467
The FactoryBot.* prefix has been removed in f08bea3467. Since then
rubocop complains about Layout/ArgumentAlignment. This commit fixes it.
* do not fix alignments for modules/*/spec yet
hoping to be under the limit of 65535 characters for reviewdog to report on rubocop errors
In the former implementation, the partial index was not used leading to timouts when fetching the count on all visible relations. On the same database, the join
based approach leads to the sql statement taking 500ms which is not yet ideal but bearable.
Updates the copyright to 2021 for all files that have a copyright. Files in our source code without the copyright header still do not receive one automatically. Additionally, backlisted files are also excluded.
Previously the copyright of chiliproject which references redmine stated a copyright of redmine up to and including 2017 which is not true for the code we have in here. Because of that I changed that to 2013
Instead of having the tree/hierarchy information for work packages and
the relations between the work packages separated into two tables all
the information is now stored in the relations table.
To support this, the typed_dag plugin is used.
Notable changes:
* relations_to and relations_from are swapped. relations_to has all
relations that point to another work package (from_id = work_package.id)
and relations_from contains all relations that lead to the work package
from another one (to_id = work_package.id). This change is merely in the
code. The db information is left untouched.
* For follows/precedes to_id and from_id are swapped in the db. Because
of that, "follows" is now the canonical name instead of "precedes". This is
done so that hierarchy relations and follows relations point into the
same direction which allows to easily detect cyclic relationships that
would lead to infinit scheduling.
* the columns `root_id`, `lft`, `rgt` do no longer exist in the wp
table.
* the column `relation_type` does no longer exist in the relations
table.
* For every type of relation a column (integer) does now exist in the
relations table (e.g. hierarchy, block, follow)
* Separate associations exist for every type of relation into two
directions. E.g. Work packages following the current one can be accessed
via `work_package.precedes`
The previous implementation to detect circular dependencies was limited to detecting those circles, that originated in the 'to' work package of a relation. It did not prevent circles where the 'from' work package is involved. Now, both branches are checked.
While this removes the immediate issue, it also increases the time required for saving a relation. As long as our database does not provide us the capacity for recursive queries, this cannot be helped.
Christophe Bliard