---
title: "Overview of Scheduling 3.0: Mechanisms, Modes, and Influences on Task Dates"
canonical: "https://support.appfire.com/space/SUPPORT/3660021781/Overview%20of%20Scheduling%203.0%3A%20Mechanisms%2C%20Modes%2C%20and%20Influences%20on%20Task%20Dates"
format: markdown
---
# Overview

**Scheduling **is** **the mechanism of calculating task periods consistent with a set of constraints while trying to maintain user intention.

**Scheduling 3.0** - the newest version of this mechanism, first released in version 8.4 and still ongoing (as of 2nd April 2024, i.e. version 8.30.0)

**Where are dates taken from:**

- Jira:
  - manually set dates by the user;
  - Automations (Script Runner, other plugins).
- BigPicture:
  - default values;
  - user intention (Resize/Move on Gantt module/Inline editing)
  - scheduling constraints;
  - <u>[Task Period Alignment](https://appfire.atlassian.net/wiki/spaces/DLP/pages/298387386)</u>.

### **Default values**

**Start Date is empty and End Date is empty**

- Start Date = Today
- End Date = Today

**Start Date is empty**

- End Date is after Today
  - Start Date = Today
  - End Date = End Date
- End Date is not after Today
  - Start Date = Today
  - End Date = Today

**End Date is empty**

- Start Date = Start Date
- End Date = Start Date

**Start Date is after End Date**

- Start Date = Start Date
- End Date = Start Date

# Scheduling Mechanism

**Criteria deciding whether the task lies under scheduling or not (1-4):**

1. Status of the task - issues in *'Closed'* status are excluded from scheduling (works all the time)
2. Status of the Box - issues from Archived or Closed Boxes are excluded from scheduling (works all the time)
3. Detecting cyclical relationship - issue is excluded from scheduling (until the cycle is solved)
4. Scheduling Mode - issues in *'manual'* and *'locked'* scheduling modes are excluded from scheduling (until scheduling mode is changed to other option)
5. **Tasks without dates (from 8.17) - **issue does not have neither of dates - issue is excluded from scheduling (until dates are set for the issue)

**Other:**

1. Sub-boxes can change dates and statuses of Sprints
2. Milestone tasks implicate limitations on changing the date

## Scheduling Drivers

### What can influence the change of the task date

1. **-CHANGE OF THE DATE -**
2. <sup>Manual change of the task date in BP (inline edit / resize on Gantt or Resources or Calendar / move on Gantt or Resources or Calendar)</sup>
3. <sup>Manual change of the task date in Jira (if BP <> Jira mapping is set)</sup>
4. <sup>Conversion to milestone → the task will be shortened to 1 day and dates converted to End Date</sup>
  
5. **- CHANGE OF THE DATE IN OE / RE -**
6. <sup>Time logging → may extend the task if the logged time exceeds the available RE (TS + RE mode)</sup>
7. <sup>Change of OE → increases or decreases the task duration (OE mode)</sup>
8. Change of RE →  increases or decreases the task duration (RE mode)
9. **- DEPENDENCIES - (constant impact)**
10. <sup>Adding a dependency to the task in BP or Jira → the task will move</sup>
11. <sup>Removing dependencies from the task in BP or Jira → loss of the constraint, the task may now be affected by another constraint</sup>
12. <sup>Changing the type of dependency in BP or Jira (e.g. to ES) → the task will move ahead of its predecessor</sup>
13. <sup>Changing the dependency type to ASAP in BP → the task may move right next to its predecessor</sup>
14. <sup>Changing lag time on a dependency → the task will move away from or move next to its predecessor</sup>
15. <sup>Inherited dependencies → if a task with a parent task in bottom-up mode has a dependency, this dependency is passed on to the children of this parent.</sup>
  1. <sup>So that moving the parent also moves the children (the bottom-up parent moves its children, but only by drag&drop, moving it with another dependency would not move its children)</sup>
  2. <sup>So that the children cannot be moved (because bottom-up children would move the parent because they control it, but the parent is held by the asap dependency, so it should not be moved)</sup>
16. **- IMPACT OF THE STRUCTURE AND SCHEDULING MODE - (constant)**
17. Move of the parent:
  1. Parent (**manual**) vs Child (any) → no impact
  2. Parent (**top-down**) vs Child (**manual**) → no impact
  3. Parent (**top-down**) vs Child (**top-down lub bottom-up**)
    1. move of the parent → moves child
    2. move of the child → possible under dates of parent, cannot exceed parent
    3. expand of the parent → no impact on children
    4. narrow down of the parent → moves children (does not change size)
    5. expand of the child → It shifts the child to the right under the parent. It’s possible to increase the size of the child so that it becomes larger than the parent — in that case, it will start aligned with the parent but extend beyond it to the right.
  4. Parent (**bottom-up**) vs Child (any)
    1. parent shift → moves child
    2. parent shift → moves child
    3. parent extension → cannot
    4. child extension → parent extension
18. The task stops being a parent because it loses its last child → loss of constraint, the task may now be affected by another constraint
19. Changing the parent's scheduling mode to bottom-up when the child is larger → the parent will adjust in size to the largest child
20. <sup>Changing the parent's scheduling mode to top-down when the child is bigger → the child will move to start with the parent</sup>
21. Changing the scheduling mode of a task when it has a parent → no impact
22. Changing Structure Builders (changing parents, inverting links)
  1. e.g. the task goes under Epic in bottom-up - Epic can change its size
23. Indentation in the structure - the child enters under the parent:
  1. Parent **manual** → no impact
  2. Parent **bottom-up** vs larger child (any) → parent will assume the size and position of the largest child
  3. Parent **top-down** vs. bigger child (**manual**) → no impact
  4. Parent **top-down** vs larger child (**top-down** or **bottom-up**) → the parent will not change its size, but will adjust the child under itself (to the right or left)
24. Indenting the structure - leaving the parent → loss of the constraint, another constraint can now start acting on the task
25. Task in scheduling mode Locked - no restrictions apply to it, it cannot be moved manually (drag & drop)
26. Task in scheduling mode Manual - no restrictions apply to it, but it can be moved manually (drag & drop)
27. Task in Done status → similarly to Locked (cannot be moved manually)
28. The task is located in another Box that is closed or archived → similarly to Locked
29. **- INFLUENCE OF PERIOD ALIGNMENT - (one time !)**
30. Changing Task period alignment in the Box configuration or on Board → bulk change of many tasks (one shot, there must be a state transition, e.g. Precise Alignment → No Alignment → Precise Alignment)
31. Changing the size of a Box that has Alignment set → does not change the size of the tasks
32. Adding a task to Box (sub-scope type that is synchronized with e.g. Jira sprint)
  1. operation on Board or
  2. by adding a task to a Sprint in Jira or
  3. by adding a task to a Sprint in BP (but Back Structure Builder must be running)
    1. in Precise Alignment mode - the task will be expanded or shortened to the width of the Box (excluding weekends)
    2. in Smart Adjustment mode - the task will keep its size (when it is smaller than the Box) or will be cut to fit the Box (when it is larger than the Box)
33. **- OTHER -**
34. Adding a task to Box (which has a dependency on another task, and this dependency was identified only after adding this task) → a limitation that may affect other tasks
35. Deleting a task from Box (removing e.g. dependencies, if the deleted task had any) → loss of restriction, another restriction may now apply to the task
36. Merge scenario → bulk change of multiple tasks
37. **- INFLUENCE OF RESOURCES and CALENDARS (not yet implemented) - (constant)**
38. Modifying the global calendar (adding holidays or rearranging weekends)
39. Modification of the calendar for a given Assignee (adding leave)
40. Modification of Assignee availability (e.g. from 100% → 50%)
41. <sup>Assigning (or changing to another) Assignee together with various criteria (local calendar, availability)</sup>

# Determinants of how a task will schedule

![image](media://1dde8129-cfbe-4041-86cc-20d0d077f97d)

**Key notes:**

- Manual scheduling consistently ignores resource calendar
- Auto bottom-up parent properly adjusts to children in all cases

# Scheduling Mode

**What actually Period means:**

- time in which task has to be done;
- set as a Start Date plus number of working days devoted to that task;
- End Date is a result of how many working days it takes from Start Date.

**Period is influenced by:**

- user intentions:
  - Resize - change of duration of the task (also by Inline editing);
  - Move - moving task on the timeline;
- calendar (weekends, absences, other holidays);
- constraints coming from Scheduling Mode (Task Mode) and task structure;
- constraints coming from Dependencies aka Links;
- if the Task is a Milestone;
- if the Task is in Done status;
- if the Task was excluded from scheduling.

**Types of Scheduling Mode (Task Mode):**

- **Auto Bottom Up**
  - Period of the task is determined by Periods of its children (if it has them);

- **Locked**
  - Period of the Task cannot be changed;
  - Sets Start and End Dates limits for its children;

- **Auto Top Down**
  - Task sets limits of its children Periods;
- **Manual**
  - Period of the task is not a part of scheduling.

| Scheduling Mode | 1. Does it apply to calendar days off?<br>(automation) | 2. Does Strong dependencies work on it?<br>(automation) | 3. Do its children influence him?<br>(automation) | 4. How does it influence his children?<br>(automation) | 5. Do its parents influence it?<br>(automation) | 6. Does it move its children with it when it is moved  automatically? | 7. Does it move with the parent that is being moved automatically? | 8. Does it move its children when it is moved by Drag & Drop? | 9. Does it move with the parent it is being moved by Drag & Drop? | 10. Does Inline date editing work on it? | 11. Can it be moved by Drag & Drop? |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| - Status = Done | :blue_star: | :cross_mark: | :cross_mark:   
(parent in ABU does not change its size) | :blue_star: | :cross_mark: | (not moved by dependencies) | :cross_mark: | :blue_star:<br>:warning: does not work for parent in ABU | :cross_mark: | :blue_star: | :blue_star: |
| ** Inactive State | :blue_star: | :cross_mark: | :cross_mark: | :blue_star: | :cross_mark: | (not moved by dependencies) | :cross_mark: | :warning: bug - not moved, but then child moves under it | :cross_mark: | :blue_star: | :blue_star: |
| Locked | :cross_mark: | :cross_mark: | :cross_mark: | :check_mark:<br>Moves children under itself | :cross_mark: | (not moved by dependencies) | :cross_mark: | :cross_mark: | :cross_mark: | :cross_mark: | :cross_mark: |
| Manual<br>(default for project, version, sprint, component) | :cross_mark: | :cross_mark: | :cross_mark: | :cross_mark: | :cross_mark: | :cross_mark:<br>(not moved by dependencies) | :cross_mark: | :cross_mark: | :cross_mark: no, with exception:<br>:check_mark: :warning:  moved only by parent in ABU | :check_mark: | :check_mark: |
| <new default> | :check_mark: automation  
(calendar) | :check_mark: automation  
(Strong links) | :cross_mark: lack of automation Parent-Child  
(like Manual) | :cross_mark: lack of automation Parent-Child  
(like Manual) | :cross_mark: lack of automation Parent-Child  
(like Manual) | :cross_mark: lack of automation Parent-Child  
(like Manual) | :cross_mark: lack of automation Parent-Child  
(like Manual) | :cross_mark: lack of  
(like Manual) | :cross_mark: no, with exception:<br>:check_mark: :warning:  moved only by parent in ABU | :check_mark: | :check_mark: |
| Top-down | :check_mark: | :check_mark: | :cross_mark: | :check_mark:<br>Moves children under itself | :check_mark:<br>> Top-down  
> Locked | :check_mark:<br>> Top-down  
> Bottom-up | :check_mark:<br>> Top-down  
> Bottom-up | :check_mark: | :check_mark: | :check_mark: | :check_mark: |
| Bottom-up<br>(default for epics, basic tasks, Jira tasks, Trello) | :check_mark: - child<br>:cross_mark: - as a parent and has children Manual / Locked set for the weekend | :check_mark:<br>:warning:  
but the influence of children Done/Manual/Locked has higher priority | :check_mark: | :cross_mark: | :check_mark:<br>> Top-down  
> Locked | :cross_mark:<br>:warning: parent is no longer moved by dependency (since 8.8) | :check_mark:<br>> Top-down  
> Bottom-up | :check_mark:<br>:warning: additional info - it also moves children that are in Manual | :check_mark: | :check_mark: only if hit is not a parent<br>:cross_mark: -<br>if it is a parent, date editing is blocked<br>(its size is the 'sum' of the sizes of its children) | :check_mark:<br>:warning: additional info - not to be moved if its children are Locked or in Done status |

- When a task enters the Done status, dependencies and parent-child relationships stop working (but the calendar still works).

  
:blue_star: → the task behaves according to the original Scheduling Mode.

** The transition of a task to the Inactive state is caused by the detection of a cyclic dependency in which the task is involved (e.g. a task has a Strong relation to its parent, or task A has a dependency to task B, and task B has a dependency to task A). We usually prevent a cycle from being created on the BP side, but we are not able to prevent it from being created on the Jira side (e.g. Strong links can be created in Jira and thus create cycles between tasks).

:warning: Note - closing a task in a Team-Managed project on Cloud causes this task to be blocked for editing on the Jira side.  
Then such a task cannot be moved or edited (BUT this is not due to the block on the BigPicture side, but due to the block on the Jira side).  
It would be worth adding a tooltip to distinguish this situation.

<u>Other rules connected to Scheduling Mode:</u>

1. for Box, we set tasks to Bottom-up mode by default (this can be changed), extra tasks (Project, Sprint, Version, Component) are set to Manual by default.
2. the ability to set Bottom-up for Sprint is blocked so that children's dates do not change sprint dates (<u>[ONE-53257](https://appfire.atlassian.net/browse/ONE-53257)</u>).
3. removing a task from scheduling (due to its status, Box status or cyclic dependency) cancels the operation of Bottom-up and Top-down modes (the task behaves as if it were in Manual mode).

# Non-working days

| Task type | Does it have dates | Scheduling mode | Can be scheduled on off-days |
| --- | --- | --- | --- |
| Milestone | none | any | :check_mark: |
| Milestone | both | any | :check_mark: |
| Task | none | any | N/A |
| Task | one | locked / manual | :check_mark: |
| Task - parent | one | bottom-up | :check_mark: |
| Task - parent | one | top-down | :cross_mark: |
| Task - child | one | top-down / bottom-up | :cross_mark: |
| Task | both | locked / manual | :check_mark: |
| Task - parent | both | bottom-up | :check_mark: |
| Task - parent | both | top-down | :cross_mark: |
| Task - child | both | top-down / bottom-up | :cross_mark: |


# Dependencies (aka Links)

- **Target task - **task, which Period is determined by the dependency;

- **Source task - **task, which Period determines the Period of the Target;

- **ASAP mode -** determines, if Period of the Target Task has to be as close as possible (same or next day) to the Period of Source Task;

- **Lag time **- number of days which is added/subtracted while calculating minimum space between Period of Source Task and Period of Target Task.

![image](media://76071cb6-1fde-4772-8a7c-60bcfb0c4c4c)

:warning: NOTE - holidays and lag time should not affect the dependency color.

Example = the ASAP dependency requires that the tasks be next to each other, but if the tasks are separated by a weekend or holiday, this is a correct situation (only working days are taken into account).

| Dependency  
ASAP |  | ok | broken | broken |
| --- | --- | --- | --- | --- |
| End → Start |  | source End Date = target Start Date | source End Date < target Start Date | source End Date > target Start Date |
| Start → Start |  | source Start Date = target Start Date | source Start Date < target Start Date | source Start Date > target Start Date |
| End → End |  | source End Date = target End Date | source End Date < target End Date | source End Date > target End Date |
| Start → End |  | source Start Date = target End Date | source Start Date < target End Date | source Start Date > target End Date |


| Dependency  
non-ASAP |  | ok | ok | broken |
| --- | --- | --- | --- | --- |
| End → Start |  | source End Date = target Start Date | source End Date < target Start Date | source End Date > target Start Date |
| Start → Start |  | source Start Date = target Start Date | source Start Date < target Start Date | source Start Date > target Start Date |
| End → End |  | source End Date = target End Date | source End Date < target End Date | source End Date > target End Date |
| Start → End |  | source Start Date = target End Date | source Start Date < target End Date | source Start Date > target End Date |


---

Task 1 - **source** (of a dependency).

Task 2 - **target** (of a dependency).

**ATTENTION** - if the Target task has a Scheduling Mode set to Manual or Locked, then dependencies do not impact dates of this task (sync with Source task is ignored).

Additional info - in general, instead of the word End, the word Finish is more often used (i.e. ES/SE/EE dependencies are marked with the symbols FS/SF/FF).

---


**ASAP mode** means that the selected date of Task 2 (target) will be permanently synchronized with the selected date of Task 1 (source).

- Moving Task 1 will **always** result in moving Task 2.
- Changing the date of Task 1 (the synchronized one) will **always** result in postponing Task 2.
- Changing the date of Task 2 (the synchronized one) will **always** restore it to its previous value (e.g. shortening the task by 2 days will move the task forward two days so that the End Date remains unchanged).


**non-ASAP mode** means that the selected date of Task (target) 2 cannot be earlier than the selected date of Task 1 (source).

- Shifting Task 1 **may** cause Task 2 to shift (to meet the above condition).
- Changing the date of Task 1 (the synchronized one) **may** cause Task 2 to be postponed (to meet the above condition).
- Changing the date of Task 2 (the one that's synchronized) **may** return it back to its previous value (e.g. extending the task by 2 days will move the task forward two days so that the Start Date remains unchanged).

# Change Log

### Why:

**Need No. 1** - user enters Gantt module in BP and presented there tasks look different visually. User does not know what has happened.

User would like to:

a) know which tasks have changed and when;

b) know what has triggered the change;

c) know who is responsible for the change;

d) know how this change on Gantt has influenced the whole net of related tasks in this project.


**Need No. 2** - user enters Gantt in BP and see that particular task has different dates or its period has changed.

User would like to:

a) know what has triggered the change;

b) know who is responsible for the change.

### Task details view

You can open the panel directly from the task details view.

1. Click on a task on the Gantt timeline
2. Click "**See changes**"
  

### Scenario mode

Changes made in scenario mode are not logged until a scenario is merged into the live version.

### Log

The change log contains data from the last **two weeks** only.

### Number of listed changes

Change log displays up to **80 positions**. To find a change that isn't visible, use the search function.

### Reason Of Change Map

Icons:

![image]()

Map

| Status | Source | Action | Event | Statement | Icon | Task ID | Translation for multiple ID |
| --- | --- | --- | --- | --- | --- | --- | --- |

| Status | Source | Action | Event | Statement | Icon | Task ID | Translation for multiple ID |
| --- | --- | --- | --- | --- | --- | --- | --- |
| :check_mark: | BP | Pressing the Undo button | UNDO | The scheduling action undone by | 9. Undo | N/A |  |
| :check_mark: | BP | Adding dependency | LINK_CREATE | Dependency added by | 1. Dependency | yes |  |
| :check_mark: | Jira | Adding dependency | LINK_CREATE | Dependency added by | 1. Dependency | yes | Multiple dependencies added by |
| :check_mark: | BP | Deleting dependency | LINK_DELETE | Dependency removed by | 1. Dependency | yes |  |
| :check_mark: | Jira | Deleting dependency | LINK_DELETE | Dependency removed by | 1. Dependency | yes | Multiple dependencies removed by |
| :check_mark: | BP | Changing dependency mode | LINK_UPDATE | Dependency updated by | 1. Dependency | yes |  |
| :check_mark: | BP | Changing lag time of dependency | LINK_UPDATE | Dependency updated by | 1. Dependency | yes |  |
| :check_mark: | BP | Move of the task | MOVE | Task moved by | 2. Move | yes | Task moved by |
|  |  |  |  |  |  |  |  |
| :check_mark: | BP | Deleting date | RESIZE  
DATE_CLEAR | Date removed by   
(when both dates are deleted)<br>New date set by   
(when one date is deleted) | 7. Calendar | yes | (Bulk change) Date removed by |
| :check_mark: | JIRA | Deleting date | EXTERNAL_RESIZE  
EXTERNAL_DATE_CLEAR | (Jira) Date removed by   
(when both dates are deleted)<br>(Jira) New date set by   
(when one date is deleted) | 7. Calendar | yes | (Bulk change) Date removed by |
| :question_mark: | Edit Task in BP | Deleting date | EXTERNAL_RESIZE  
EXTERNAL_DATE_CLEAR | (Jira) Date removed by   
(when both dates are deleted)<br>(Jira) New date set by   
(when one date is deleted) | 7. Calendar | yes | (Bulk change) Date removed by |
| :check_mark: | BP | Changing date or field Duration WD | RESIZE | New date set by | 7. Calendar | yes | (Bulk change) Date changed by |
| :check_mark: | Jira | Changing date or field Duration WD | EXTERNAL_RESIZE | ** **(Jira) New date set by | 7. Calendar | yes | (Bulk change) Date changed by |
| :check_mark: | Edit Task in BP | Changing date | EXTERNAL_RESIZE | ** **(Jira) New date set by | 7. Calendar | yes | (Bulk change) Date changed by |
|  |  |  |  |  |  |  |  |
| :cross_mark:<br>9/05/2023 | BP | Mapping switch that changes task dates (based on OE/RE/TS fields) | HANDLING_AEM_EVENTS | Scheduling change by | 3. Time | no | (Bulk change) Tasks valuation changed by |
| :check_mark: :warning:   
9/05/2023 | BP | Changing OE or RE | EXTERNAL_RESIZE | ** **(Jira) New date set by | 3. Time | yes | (Bulk change) Tasks valuation changed by |
| :check_mark: :warning:  
9/05/2023 | Jira | Logging time, changing OE or RE | EXTERNAL_RESIZE | ** **(Jira) New date set by | 3. Time | yes | (Bulk change) Tasks valuation changed by |
| :check_mark: :warning:  
9/05/2023 | Edit Task in BP | Logging time, changing OE or RE | EXTERNAL_RESIZE | ** **(Jira) New date set by | 3. Time | yes | (Bulk change) Tasks valuation changed by |
|  |  |  |  |  |  |  |  |
| :check_mark: | BP | Converting to milestone | MILESTONE_STATUS_CHANGED | Task converted to a milestone by | 8. Milestone | yes |  |
| :check_mark: | Jira | Converting to milestone | MILESTONE_STATUS_CHANGED | Task converted to a milestone by | 8. Milestone | yes | Multiple tasks converted to milestones by |
| :question_mark: | BP | Converting from milestone to task | MILESTONE_TO_TASK_CHANGED | Milestone converted to a task by | 8. Milestone | yes |  |
| :question_mark: | Jira | Converting from milestone to task | MILESTONE_TO_TASK_CHANGED | Milestone converted to a task by | 8. Milestone | yes |  |
|  |  |  |  |  |  |  |  |
| :check_mark: | BP | Changing Task Scheduling Mode | TASK_MODE_CHANGED | Scheduling Mode changed by | 4. Inheritance | yes | (Bulk change) Scheduling Mode changed by |
| :check_mark: | Jira | Changing Task Scheduling Mode | TASK_MODE_CHANGED | Scheduling Mode changed by | 4. Inheritance | yes | (Bulk change) Scheduling Mode changed by |
| :check_mark: | Edit Task in BP | Changing Task Scheduling Mode | TASK_MODE_CHANGED | Scheduling Mode changed by | 4. Inheritance | yes | (Bulk change) Scheduling Mode changed by |
| :check_mark: | BP | Changing BOX Precise Alignment | BOX_PERIOD_ALIGNMENT_CHANGED | Box Alignment changed by | 4. Inheritance | N/A | N/A |
| :check_mark: | BP | Changing task status | TASK_STATUS_CHANGED | Task status changed by | 10. Status | yes | (Bulk change) Task status changed by |
| :check_mark: | Jira | Changing task status | TASK_STATUS_CHANGED | Task status changed by | 10. Status | yes | (Bulk change) Task status changed by |
|  |  |  |  |  |  |  |  |
| :question_mark: | BP | Adding a task that extends the project | TASK_ADDED<br>ale czasami zamiast tego przyjdzie<br>HANDLING_AEM_EVENTS (bug) | Task added by<br>or<br>Scheduling change by | 5. Structure | yes | Tasks added by |
| :question_mark: | Jira | Adding a task that extends the project | TASK_ADDED<br>ale czasami zamiast tego przyjdzie<br>HANDLING_AEM_EVENTS (bug) | Task added by<br>or<br>Scheduling change by | 5. Structure | yes | Tasks added by |
| :check_mark: | BP | Making an indent or outdent in a structure that changes the parent | PARENT_CHILD_RELATION_CHANGED | Parent changed by | 5. Structure | yes | Parents changed by |
| :check_mark: | Jira | Making an indent or outdent in a structure that changes the parent | PARENT_CHILD_RELATION_CHANGED | Parent changed by | 5. Structure | yes | Parents changed by |
| :check_mark: | BP | Changing Structure Builders or Link Direction | PARENT_CHILD_RELATION_CHANGED | Parent changed by | 5. Structure | yes | Parents changed by |
| :check_mark: | BP | Adding a task to the Box with Structure Builder, the task moves to its parent | PARENT_CHILD_RELATION_CHANGED | Parent changed by | 5. Structure | yes | Parents changed by |
| :check_mark:  
9/05/2023 | BP | Changing Task Structure | PARENT_CHILD_RELATION_CHANGED | Parent changed by | 5. Structure | yes | Parents changed by |
|  |  |  |  |  |  |  |  |
| :check_mark: | BP | Deleting task | ?? | Task removed by | 5. Structure | N/A |  |
| :check_mark: | Jira | Deleting task | ?? | Task removed by | 5. Structure | N/A |  |
| :check_mark:  
9/05/2023 | BP | Changing BOX status |  | Dependency added by (System user) | 5. Structure | N/A | N/A |
| :check_mark: |  | Unknown event |  | Unspecified reason | X. Default | N/A | N/A |
|  |  |  | == NOT IMPLEMENTED == |  |  |  |  |
| ? | BP | Modification of the global calendar | ? | Global calendar changed | 7. Calendar | x |  |
| ? | BP | <sup>Modification of the Assignee / holiday calendar</sup> | ? | Assignee's calendar changed | 7. Calendar | x |  |
| ? | BP | Change of Assignee | ? | Assignee changed by | 6. Assignee |  |  |
| ? | Jira | Change of Assignee | ? | Assignee changed by | 6. Assignee |  |  |

# Summary - Key changes

### Changes for Support and clients:

1. (removed from scheduling) if there is a cycle relationship, then BP excludes one of tasks from scheduling in order to cut such cycle (this task is marked).
2. (removed from scheduling) tasks that are in Closed or Archived Boxes are excluded from scheduling, which requires when the task is not scheduled properly, to check if it isn't by any chance still in other Box that is Closed or Archived.
3. (removed from scheduling) tasks in Done status are excluded from scheduling.
4. (top-down) Parent in top-down Scheduling Mode cannot 'cut' children Scheduling Modes to it's size (if a child task is bigger than the parent), it can only move it (no symmetry compared to bottom-up, where children can resize their parent).
5. (UI improvement) colored background on Gantt, when moving/resizing the task, together with info that this task cannot be in this particular area, due to other different constraints.
6. (UI improvement) dotted links - show dependency, which influences the task indirectly, when the dependency is linked to the parent of this task (therefore this dependency influences this task through its parent).
7. (UI) no acyclic report (no need due to the working mechanism).