TimePhasedTaskModel

The scheduling direction of this event. The Forward direction corresponds to the as-soon-as-possible scheduling (ASAP), Backward - to as-late-as-possible (ALAP). The ASAP tasks "sticks" to the project's start date, and ALAP tasks - to the project's end date.

If not specified (which is the default), direction is inherited from the parent task (and from the project for top-level tasks). By default, the project model has forward scheduling mode.

Note The ALAP-scheduled task in the ASAP-scheduled project will turn all of its successors into ALAP-scheduled tasks, even if their scheduling direction is specified explicitly by the user as ASAP. We can say that ALAP-scheduling is propagated down through the successors chain. This propagation, however, will stop in the following cases:

• If a successor is manually scheduled
• If a successor has a "Must start/finish on" constraint
• If a dependency to successor is inactive

Similarly, the ASAP-scheduled task in the ALAP-scheduled project will turn all of its predecessors into ASAP-scheduled tasks (also regardless of the user-provided value).

When such propagation is in action, the value of this field is ignored and the UI will disable controls for it.

To determine the actual scheduling direction of the task (which might be different from the user-provided value), one can use the effectiveDirection field.

Note For the purposes of compatibility with MS Project and to ease the migration process for users, by default, scheduling direction can be set using the "Constraint type" field on the "Advanced" tab of the task editor. The forward scheduling is specified in it as "As soon as possible" option and backward - "As late as possible". One can also disable the includeAsapAlapAsConstraints config to render a separate "Scheduling direction" field.

Flag the record as read-only on the UI level, preventing the end user from manipulating it using editing features such as cell editing and event dragging.

Does not prevent altering the record programmatically, it can still be manipulated by application code.

For more info, see the "Read-only records" section above.

The current timeZone this record is converted to. Used internally to keep track of time zone conversions.

Can also be used to create a new record with dates in a specific non-local timezone. That is useful for example when replacing a store dataset. That would be interpreted as a new load, and all dates would be converted to the configured timezone.

If specifically set to null when adding a new record to a Store, the new record's dates will be converted to the Project's configured timezone.

If set to false on a record, that record will be excluded from timezone conversion.

For more information about timezone conversion, se timeZone.

This field will not persist by default.

The getter will yield a Store of Baselines.

When constructing a task the baselines will be constructed from an array of Baseline data objects.

When serializing, it will yield an array of Baseline data objects.

Child nodes. To allow loading children on demand, specify children : true in your data. Omit the field for leaf tasks.

Note, if the tree store loads data from a remote origin, make sure readUrl is specified, and optionally parentIdParamName is set, otherwise loadChildren has to be implemented.

Shows the amount of effort that has already been done by resources assigned to the task.

For a summary task the value is calculated as sum of children actual effort values. Otherwise if the task has assignments the value is calculated as sum of assignments actual efforts. And if not the value is calculated as effort multiplied by percentDone value.

A deadline date for this task. Does not affect scheduling logic.

Note that the field always returns a Date.

The numeric part of the task duration (the number of units).

UI fields representing this data field are disabled for summary events except the manually scheduled events. See isEditable for details.

The unit part of the task duration, defaults to "day" (days). Valid values are:

It also supports e* (elapsed) duration units, where tasks run continuously 24 hours a day, 7 days a week, ignoring all non-working time, ideal for tasks that need to run without breaks or for rough project planning with limited date/duration info.

For example:

new TaskModel({
    startDate    : '2024-09-10',
    endDate      : '2024-09-17',
    duration     : 7,
    durationUnit : 'ed'
});

This field is readonly after creation, to change it use the setDuration call.

A calculated field storing the early end date of the task. The early end date is the earliest possible date the task can finish. This value is calculated based on the earliest dates of the task predecessors and the task own constraints. If the task has no predecessors nor other constraints, its early end date matches the project start date plus the task duration.

UI fields representing this data field are naturally disabled since the field is readonly. See isEditable for details.

A calculated field storing the early start date of the task. The early start date is the earliest possible date the task can start. This value is calculated based on the earliest dates of the task predecessors and the task own constraints. If the task has no predecessors nor other constraints, its early start date matches the project start date.

UI fields representing this data field are naturally disabled since the field is readonly. See isEditable for details.

The numeric part of the task effort (the number of units). The effort of the "parent" tasks will be automatically set to the sum of efforts of their "child" tasks

UI fields representing this data field are disabled for summary events. See isEditable for details.

The unit part of the task's effort, defaults to "h" (hours). Valid values are:

• "millisecond" - Milliseconds
• "second" - Seconds
• "minute" - Minutes
• "hour" - Hours
• "day" - Days
• "week" - Weeks
• "month" - Months
• "quarter" - Quarters
• "year"- Years

This field is readonly after creation, to change it use the setEffort call.

End date of the task in ISO 8601 format

UI fields representing this data field are disabled for summary events except the manually scheduled events. See isEditable for details.

Note that the field always returns a Date.

When set to true the calendars of the assigned resources are not taken into account when scheduling the task.

By default the field value is false resulting in that the task performs only when its own calendar and some of the assigned resource calendars allow that.

A calculated field storing the late end date of the task. The late end date is the latest possible date the task can finish. This value is calculated based on the latest dates of the task successors and the task own constraints. If the task has no successors nor other constraints, its late end date matches the project end date.

UI fields representing this data field are naturally disabled since the field is readonly. See isEditable for details.

A calculated field storing the late start date of the task. The late start date is the latest possible date the task can start. This value is calculated based on the latest dates of the task successors and the task own constraints. If the task has no successors nor other constraints, its late start date matches the project end date minus the task duration.

UI fields representing this data field are naturally disabled since the field is readonly. See isEditable for details.

The field contains a postponed unresolved scheduling conflict the task (if any).

The conflict postponing functionality can be activated with the allowPostponedConflicts and autoPostponeConflicts configuration options, Please refer to those docs for additional details.

Specifies how the task should treat the project border (the project start or end depending if it's scheduled forward or backwards respectively).

The task can either respect the project border which for example means it cannot be placed before its forward scheduled project start. Or the task can ignore the project border and be scheduled regardless of that constraint.

Possible values are:

• honor - task respects the project border.
• ignore - task ignores the project border.
• conflict - the project triggers schedulingConflict event when the task attempts to violate its border. So if Gantt has displaySchedulingIssueResolutionPopup enabled it will display a popup asking user to choose an appropriate resolution. If the option is disabled the application can track the event and implement some other way to handle the conflict.

This field defines the scheduling mode for the task. Based on this field some fields of the task will be "fixed" (should be provided by the user) and some - computed.

Possible values are:

• Normal is the default (and backward compatible) mode. It means the task will be scheduled based on information about its start/end dates, task own calendar (project calendar if there's no one) and calendars of the assigned resources.

• FixedDuration mode means, that task has fixed start and end dates, but its effort will be computed dynamically, based on the assigned resources information. Typical example of such task is - meeting. Meetings typically have pre-defined start and end dates and the more people are participating in the meeting, the more effort is spent on the task. When duration of such task increases, its effort is increased too (and vice-versa). Note: fixed start and end dates here doesn't mean that a user can't update them via GUI, the only field which won't be editable in GUI is the effort field, it will be calculated according to duration and resources assigned to the task.

• FixedEffort mode means, that task has fixed effort and computed duration. The more resources will be assigned to this task, the less the duration will be. The typical example will be a "paint the walls" task - several painters will complete it faster.

• FixedUnits mode means, that the assignment level of all assigned resources will be kept as provided by the user, and either effort or duration of the task is recalculated, based on the effortDriven flag.

Start date of the task in ISO 8601 format

UI fields representing this data field are disabled for summary events except the manually scheduled events. See isEditable for details.

Note that the field always returns a Date.

A calculated field storing the total slack (or total float) of the task. The total slack is the amount of working time the task can be delayed without causing a delay to the project end. The value is expressed in slackUnit units.

// let output slack info to the console
console.log(`The ${task.name} task can be delayed for ${task.totalSlack} ${slackUnit}s`)

UI fields representing this data field are naturally disabled since the field is readonly. See isEditable for details.

This field is automatically set to true when the task is "unscheduled" - user has provided an empty string in one of the UI editors for start date, end date or duration. Such task is not rendered, and does not affect the schedule of its successors.

To schedule the task back, enter one of the missing values, so that there's enough information to calculate start date, end date and duration.

Note, that setting this field manually does nothing. This field should be persisted, but not updated manually.

The WBS for this task record. This field is automatically calculated and maintained by the store. This calculation can be refreshed by calling refreshWbs.

To get string representation of the WBS value (e.g. '2.1.3'), use value property.

An encapsulation of the CSS classes to be added to the rendered event element.

Always returns a DomClassList, but may still be treated as a string. For granular control of adding and removing individual classes, it is recommended to use the DomClassList API.

Changes task's background color. Named colors are applied as a b-color-{color} (for example b-color-red) CSS class to the task's bar. Colors specified as hex, rgb() etc. are applied as a --b-primary CSS variable to the bar.

If no color is specified, any color defined in Gantt's eventColor config will apply instead.

For available standard colors, see EventColor.

Using named colors:

const gantt = new Gantt({
    project {
        tasks : [
            { id : 1, name : 'Important task', eventColor : 'red' }
        ]
    }
});

Will result in:

<div class="b-gantt-task-wrap b-color-red">

Using non-named colors:

const gantt = new Gantt({
    project {
        tasks : [
            { id : 1, name : 'Important task', eventColor : '#ff0000' }
        ]
    }
});

Will result in:

<div class="b-gantt-task-wrap" style="--b-primary: #ff0000">

This field is added to the class at runtime when the Store is configured with lazyLoad. If set on a parent record at load time, that parent will not cause any more child load requests. If omitted, it will be automatically set to true when a load request receives fewer child records than requested.

To specifically set this field for a parent at its children load request, provide it as a property in the data response object:

return {
   data : [ ... ],
   isFullyLoaded : true
   total : 123
}

Or to include grandchildren for a parent, it can be provided as a property on the record data object:

return {
   data : [{
      id : 1,
      name : 'My Parent',
      isFullyLoaded : true,
      expanded : true,
      children : [{
         id : 2,
         name : 'My Child'
     }]
   }],
   total : 123
}