ProjectModel

When set to true, pins a task at its starting date. Otherwise, it is rescheduled to the project's starting date if there is no predecessor or constraint supplied.

When a dataset is loaded without using any constraints, dependencies, or manually scheduled tasks, the tasks are moved to the project's start date. Setting autoSetConstraints to true avoids this behaviour by showing your tasks based on their startDate and endDate. To see it in action, check out the auto constraints demo.

By default, the stores of a project use the raw data objects passed to them as the data source for their records if data is loaded remotely (using an AjaxStore or a CrudManager). For data supplied inline, the data objects are instead by default cloned to avoid the original data object being modified by the store.

See useRawData for more information on the mechanics of this.

This can be explicitly controlled per store by setting the useRawData config on the store:

// Opt in for a single store
const project = new ProjectModel({
    eventStore : {
      useRawData : true
    },
    ...
});

Or you can control it for all the default stores in the project by setting this config on the project:

// Opt in for all stores in the project
const project = new ProjectModel({
   useRawData : true,
   ...
});

This config manages DST correction in the scheduling engine. It only has effect when DST transition hour is working time. Usually DST transition occurs on Sunday, so with non working weekends the DST correction logic is not involved.

If true, it will add/remove one hour when calculating duration from start/end dates. For example: Assume weekends are working and on Sunday, 2020-10-25 at 03:00 clocks are set back 1 hour. Assume there is a task:

{
    startDate    : '2020-10-20',
    duration     : 10,
    durationUnit : 'day'
}

It will end on 2020-10-29 23:00. Because of the DST transition Sunday is actually 25 hours long and when the Gantt project calculates the end date it converts days to hours multiplying by 24. If you're setting duration and want task to end on the end of the day you should manually correct for DST, like so:

{
    startDate    : '2020-10-20',
    duration     : 10 * 24 + 1,
    durationUnit : 'hour'
},

If task has start and end dates it will correct for DST twice:

{
    startDate    : '2020-10-20',
    endDate      : '2020-10-30'
}

This task will end on 2020-10-29 22:00 which is a known quirk.

If false, the Gantt project will not add DST correction which fixes the quirk mentioned above and such task will end on 2020-10-30 exactly, having hours duration of 10 days * 24 hours + 1 hour.

Also, for this task days duration will be a floating point number due to extra (or missing) hour:

task.getDuration('day')  // 10.041666666666666
task.getDuration('hour') // 241

Enables early rendering in Gantt, by postponing calculations to after the first refresh.

Requires task data loaded in Gantt to be pre-normalized to function as intended, since it will be used to render tasks before engine has normalized the data. Given un-normalized data tasks will snap into place when calculations are finished.

The Gantt chart will be read-only until the initial calculations are finished.

Set to true to enable calculation progress notifications. When enabled, the project fires progress events and the Gantt chart load mask reacts by showing a progress bar for the Engine calculations.

Note: Enabling progress notifications will impact calculation performance, since it needs to pause calculations to allow the UI to redraw.

Maximum range the project calendars can iterate. The value is defined in milliseconds and by default equals 5 years roughly.

new Gantt({
    project : {
        // adjust calendar iteration limit to 10 years roughly:
        // 10 years expressed in ms
        maxCalendarRange : 10 * 365 * 24 * 3600000,
        ...
    }
});

Setting this to true (default) vetoes silenceInitialCommit effect by preventing silent changes accepting on initial data loading if some scheduling issue gets resolved during it.

Enabling this config allows an application to persist the data in a resolved state.

Set to true to reset the undo/redo queues of the internal StateTrackingManager after the Project has loaded. Defaults to false

Experimental hook that lets the app determine if a bound dataset needs syncing with the store or not, and if it does - which records that should be processed. Only called for stores that are configured with syncDataOnLoad: true (which is the default in the React, Angular and Vue wrappers).

The main use case for this is for frameworks that update all state on any state change (like React), to not have to reapply the full bound dataset each time (which becomes costly).

If the app has a cheap way of determining (for example using a timestamp) that the dataset has no changes, return false from this hook to prevent the store from syncing at all at that time.

shouldSyncDataOnLoad({ store, data }) {
  if (store === myEventStore && timestamp <= lastUpdateTimestamp) {
    // Prevent sync when the event store has not changed since last time
    // (pseudocode)
    return false;
  }
}

If the app knows that something has changed, return a Set with ids for the records that should be further processed by the sync logic.

shouldSyncDataOnLoad({ store, data }) {
  if (store === myEventStore && timestamp > lastUpdateTimestamp) {
    // Sync only these records (pseudocode)
    return new Set([6, 110, 586]);
  }
}

Silences propagations caused by the project loading.

Applying the loaded data to the project occurs in two basic stages:

1. Data gets into the engine graph which triggers changes propagation
2. The changes caused by the propagation get written to related stores

Setting this flag to true makes the component perform step 2 silently without triggering events causing reactions on those changes (like sending changes back to the server if autoSync is enabled) and keeping stores in unmodified state.

This is safe if the loaded data is consistent so propagation doesn't really do any adjustments. By default the system treats the data as consistent so this option is true.

new Gantt({
    project : {
        // We want scheduling engine to recalculate the data properly
        // so then we could save it back to the server
        silenceInitialCommit : false,
        ...
    }
    ...
})

Configuration options to provide to the STM manager

Set to a IANA time zone (i.e. Europe/Stockholm) or a UTC offset in minutes (i.e. -120). This will convert all events, tasks and time ranges to the specified time zone or offset. It will also affect the displayed timeline's headers as well at the start and end date of it.

There is currently no built-in time zone support in JavaScript which means that the converted dates technically still are in the local system time zone, but adjusted to match the configured time zone.

DST

If a IANA time zone is provided, there will be support for DST. But if local system time zone has DST that will affect the time zone conversion at the exact hour when the local system time zone switches DST on and off.

For example:

1. The local system time zone is Europe/Stockholm (which is UTC+1 or UTC+2 when DST).
2. The date 2022-03-27T07:00:00Z (which is UTC) is converted to America/Chicago (which is UTC-6 or UTC-5 when DST).
3. The converted JS date will be created from 2022-03-27T02:00:00 which is exactly the hour when Europe/Stockholm adds an DST hour. This has the effect that the converted date shows up incorrectly as 2022-03-27T03:00 instead.

If a UTC offset is provided, there is no DST support at all.

Editing

If creating new records or editing existing record dates, the dates will be interpreted as in the selected time zone.

If you want to create new records with dates that either should be interpreted as local system time zone or from any other time zone, specify the timeZone field on the record.

Saving

When saving or syncing data, the dates will be restored to local system time and converted to JSON ISO formatted. When restoring, it adds or subtracts the time difference accordingly. For instance, if the current timezone is UTC and you're in UTC +3, 3 hours will be added to the time.

The store.toJSON() and model.toJSON() methods also restores the data. For example, eventStore.toJSON() will show the dates in local timezone.

Data use to fill the assignmentStore. Should be an array of AssignmentModels or its configuration objects.

Data use to fill the calendarManagerStore. Should be a CalendarModel array or its configuration objects.

Data use to fill the dependencyStore. Should be an array of DependencyModels or its configuration objects.

Project data as a JSON string, used to populate its stores.

const project = new ProjectModel({
    json : '{"events":[...],"resources":[...],...}'
}

Data use to fill the resourceStore. Should be an array of ResourceModels or its configuration objects.

Data use to fill the taskStore. Should be an array of TaskModels or its configuration objects.

Data use to fill the timeRangeStore. Should be an array of TimeRangeModels or its configuration objects.

Specifies the output format of toJSON.

• inlineData - Return all crud store data, plus this project fields (under the project key). For example:

{
    "project" : {
        "startDate"    : "2024-03-22",
        "endDate"      : "2024-04-22",
        "hoursPerDay"  : 8,
        "daysPerWeek"  : 5,
        "daysPerMonth" : 20
    },
    "events"             : [...],
    "resources"          : [...],
    "assignments"        : [...],
    "dependencies"       : [...],
    "resourceTimeRanges" : [...],
    "timeRanges"         : [...]
}

• model - Return only the project fields. For example:

{
    "startDate"    : "2024-03-22",
    "endDate"      : "2024-04-22",
    "hoursPerDay"  : 8,
    "daysPerWeek"  : 5,
    "daysPerMonth" : 20
}

The initial data, to fill the assignmentStore with. Should be an array of AssignmentModels or configuration objects.

The initial data, to fill the calendarManagerStore with. Should be an array of CalendarModels or configuration objects.

The initial data, to fill the dependencyStore with. Should be an array of DependencyModels or configuration objects.

Alias to tasksData.

Whether to include legacy data properties in the JSON / inlineData output. The legacy data properties are the xxData (eventsData, resourcesData etc.) properties that are deprecated and will be removed in the future.

The initial data, to fill the resourceStore with. Should be an array of ResourceModels or configuration objects.

The initial data, to fill the taskStore with. Should be an array of TaskModels or configuration objects.

The initial data, to fill the timeRangeStore with. Should be an array of TimeRangeModels or configuration objects.

The constructor of the assignment model class, to be used in the project. Will be set as the modelClass property of the assignmentStore

An AssignmentStore instance or a config object.

The constructor to create a dependency store instance with. Should be a class, subclassing the AssignmentStore

A CalendarManagerStore instance or a config object.

The constructor to create a calendar store instance with. Should be a class, subclassing the CalendarManagerStore

The constructor of the calendar model class, to be used in the project. Will be set as the modelClass property of the calendarManagerStore

The constructor of the dependency model class, to be used in the project. Will be set as the modelClass property of the dependencyStore

A DependencyStore instance or a config object.

The constructor to create a dependency store instance with. Should be a class, subclassing the DependencyStore

A TaskStore instance or a config object.

The constructor of the resource model class, to be used in the project. Will be set as the modelClass property of the resourceStore

A ResourceStore instance or a config object.

The constructor to create a dependency store instance with. Should be a class, subclassing the ResourceStore

The constructor of the event model class, to be used in the project. Will be set as the modelClass property of the eventStore

An alias for the eventStore.

The constructor to create an task store instance with. Should be a class, subclassing the TaskStore

Store that holds time ranges - instances of TimeRangeModel for the TimeRanges feature. A store will be automatically created if none is specified.

Enables backward compatible conflicts postponing logic covering only conflicts between a task constraint and its incoming dependencies.

The project calendar.

Whether to include "As soon as possible" and "As late as possible" in the list of the constraints, for compatibility with the MS Project. Enabled by default.

Note, that when enabling this option, you can not have a regular constraint on the task and ASAP/ALAP flag in the same time.

See also docs of the direction field.

Enables/disables the calculation progress notifications.

Experimental hook that lets the app determine if a bound dataset needs syncing with the store or not, and if it does - which records that should be processed. Only called for stores that are configured with syncDataOnLoad: true (which is the default in the React, Angular and Vue wrappers).

The main use case for this is for frameworks that update all state on any state change (like React), to not have to reapply the full bound dataset each time (which becomes costly).

If the app has a cheap way of determining (for example using a timestamp) that the dataset has no changes, return false from this hook to prevent the store from syncing at all at that time.

shouldSyncDataOnLoad({ store, data }) {
  if (store === myEventStore && timestamp <= lastUpdateTimestamp) {
    // Prevent sync when the event store has not changed since last time
    // (pseudocode)
    return false;
  }
}

If the app knows that something has changed, return a Set with ids for the records that should be further processed by the sync logic.

shouldSyncDataOnLoad({ store, data }) {
  if (store === myEventStore && timestamp > lastUpdateTimestamp) {
    // Sync only these records (pseudocode)
    return new Set([6, 110, 586]);
  }
}

State tracking manager instance the project relies on

Set to a IANA time zone (i.e. Europe/Stockholm) or a UTC offset in minutes (i.e. -120). This will convert all events, tasks and time ranges to the specified time zone or offset. It will also affect the displayed timeline's headers as well at the start and end date of it.

There is currently no built-in time zone support in JavaScript which means that the converted dates technically still are in the local system time zone, but adjusted to match the configured time zone.

DST

If a IANA time zone is provided, there will be support for DST. But if local system time zone has DST that will affect the time zone conversion at the exact hour when the local system time zone switches DST on and off.

For example:

1. The local system time zone is Europe/Stockholm (which is UTC+1 or UTC+2 when DST).
2. The date 2022-03-27T07:00:00Z (which is UTC) is converted to America/Chicago (which is UTC-6 or UTC-5 when DST).
3. The converted JS date will be created from 2022-03-27T02:00:00 which is exactly the hour when Europe/Stockholm adds an DST hour. This has the effect that the converted date shows up incorrectly as 2022-03-27T03:00 instead.

If a UTC offset is provided, there is no DST support at all.

Editing

If creating new records or editing existing record dates, the dates will be interpreted as in the selected time zone.

If you want to create new records with dates that either should be interpreted as local system time zone or from any other time zone, specify the timeZone field on the record.

Saving

When saving or syncing data, the dates will be restored to local system time and converted to JSON ISO formatted. When restoring, it adds or subtracts the time difference accordingly. For instance, if the current timezone is UTC and you're in UTC +3, 3 hours will be added to the time.

The store.toJSON() and model.toJSON() methods also restores the data. For example, eventStore.toJSON() will show the dates in local timezone.

Get/set assignmentStore data.

Always returns an array of AssignmentModels but also accepts an array of its configuration objects as input.

Get/set calendarManagerStore data.

Always returns a CalendarModel array but also accepts an array of its configuration objects as input.

Get/set dependencyStore data.

Always returns an array of DependencyModels but also accepts an array of its configuration objects as input.

Get or set data of project stores. The returned data is identical to what toJSON returns:

const data = scheduler.project.inlineData;

// data:
{
    tasks : [
        { id : 1, name : 'Proof-read docs', startDate : '2017-01-02', endDate : '2017-01-09' },
        { id : 2, name : 'Release docs', startDate : '2017-01-09', endDate : '2017-01-10' }
    ],
    resources : [
        { id : 1, name : 'Arcady' },
        { id : 2, name : 'Don' }
    ],
    dependencies : [
        { fromTask : 1, toTask : 2 }
    ],
    assignments : [
         { 'event' : 1, 'resource' : 1 },
         { 'event' : 2, 'resource' : 2 }
     ]
}

// Plug it back in later
scheduler.project.inlineData = data;

Get or set project data (records from its stores) as a JSON string.

Get a JSON string:

const project = new ProjectModel({
    events       : [...],
    resources    : [...],
    assignments  : [...],
    dependencies : [...]
});

const jsonString = project.json;

// jsonString:
'{"events":[...],"resources":[...],...}'

Set a JSON string (to populate the project stores):

project.json = '{"events":[...],"resources":[...],...}'

Get/set resourceStore data.

Always returns an array of ResourceModels but also accepts an array of its configuration objects as input.

Get/set taskStore data.

Always returns an array of TaskModels but also accepts an array of its configuration objects as input.

Get/set timeRangeStore data.

Always returns an array of TimeSpans but also accepts an array of its configuration objects as input.

Whether to include legacy data properties in the JSON / inlineData output. The legacy data properties are the xxData (eventsData, resourcesData etc.) properties that are deprecated and will be removed in the future.

The store holding the assignment information.

See also AssignmentModel

The store holding the calendar information.

See also CalendarModel

Returns current Project changes as an object consisting of added/modified/removed arrays of records for every managed store. Returns null if no changes exist. Format:

{
    resources : {
        added    : [{ name : 'New guy' }],
        modified : [{ id : 2, name : 'Mike' }],
        removed  : [{ id : 3 }]
    },
    events : {
        modified : [{  id : 12, name : 'Cool task' }]
    },
    ...
}

The store holding the dependency information.

See also DependencyModel

The store holding the task information.

See also TaskModel

The store holding the resources that can be assigned to the tasks in the task store.

See also ResourceModel

An alias for the eventStore.

See also TaskModel

The store containing time ranges to be visualized.

See also TimeSpan

Class implementing a task segment. Can be used for customizing the class implementing segments:

// new class for a segment
class MySegment extends EventSegmentModel {
    static fields = [
       { name : 'responsiblePerson' }
    ];
}
new Gantt({
    project : {
        // tell the project to use the new class for segments
        segmentModelClass : MySegment
    }
})

Returns an array of critical paths. Each critical path is an array of critical path nodes. Each critical path node is an object which contains critical task and dependency leading to the next critical path node. Dependency is missing if it is the last critical path node in the critical path. To highlight critical paths, enable CriticalPaths feature.

// This is an example of critical paths structure
[
     // First path
     [
         {
             event : Gantt.model.TaskModel
             dependency : Gantt.model.DependencyModel
         },
         {
             event : Gantt.model.TaskModel
         }
     ],
     // Second path
     [
         {
             event : Gantt.model.TaskModel
         }
     ]
     // and so on....
]

For more details on the critical path method theory please check this article.

Overrides the project owned store identifiers calculation and launches rescheduling.

Accepts a "data package" consisting of data for the projects stores, which is then loaded into the stores.

The package can hold data for TaskStore, AssignmentStore, ResourceStore, DependencyStore and Calendar Manager. It uses the same format as when creating a project with inline data:

await project.loadInlineData({
    tasks : [
        { id : 1, name : 'Proof-read docs', startDate : '2017-01-02', endDate : '2017-01-09' },
        { id : 2, name : 'Release docs', startDate : '2017-01-09', endDate : '2017-01-10' }
    ],
    resources : [
        { id : 1, name : 'Arcady' },
        { id : 2, name : 'Don' }
    ],
    dependencies : [
        { fromTask : 1, toTask : 2 }
    ],
    assignments : [
         { 'event' : 1, 'resource' : 1 },
         { 'event' : 2, 'resource' : 2 }
     ]
     calendars    : [
         {
             id        : 111,
             name      : 'My cool calendar',
             intervals : [
                 {
                     recurrentStartDate : 'on Sat',
                     recurrentEndDate   : 'on Mon',
                     isWorking          : false
                 }
             ]
         }
     ]
});

After populating the stores it commits the project, starting its calculations. By awaiting loadInlineData() you can be sure that project calculations are finished.

Returns the data from the records of the projects stores, in a format that can be consumed by loadInlineData().

Used by JSON.stringify to correctly convert this record to json.

The output format is determined by the value of toJSONResultFormat, as follows:

• inlineData - Returns all crud store data, plus the project fields (under the project key)
• model - Returns only the project fields

const project = new ProjectModel({
    // Include both store data and project model fields in toJSON() result
    toJSONResultFormat     : 'inlineData',
    events             : [...],
    resources          : [...],
    assignments        : [...],
    dependencies       : [...],
    resourceTimeRanges : [...],
    timeRanges         : [...]
});

const json = project.toJSON();

// json:
{
    events             : [...],
    resources          : [...],
    assignments        : [...],
    dependencies       : [...],
    ...
    project                : {
        addConstraintOnDateSet : false,
        daysPerMonth           : 13
        daysPerWeek            : 3
        ...
    },
    ...
}

Output can be consumed by loadInlineData():

const json = project.toJSON();

// Plug it back in later
project.loadInlineData(json);

Defines if the given project field should be manually editable in UI. You can override this method to provide your own logic.

Sets the project start date and commits the changes.

Project changes (CRUD operations to records in its stores) are automatically committed on a buffer to the underlying graph based calculation engine. The engine performs it calculations async.

By calling this function, the commit happens right away. And by awaiting it you are sure that project calculations are finished and that references between records are up to date.

The returned promise is resolved with an object. If that object has rejectedWith set, there has been a conflict and the calculation failed.

// Move a task in time
taskStore.first.shift(1);

// Trigger calculations directly and wait for them to finish
const result = await project.commitAsync();

if (result.rejectedWith) {
    // there was a conflict during the scheduling
}

Returns a calendar of the project. If task has never been assigned a calendar a project's calendar will be returned.

Causes the scheduling engine to re-evaluate the task data and all associated data and constraints and apply necessary changes.

Resume propagation. If propagation is resumed (calls may be nested which increments a suspension counter), then if a call to propagate was made during suspension, propagate is executed.

Sets the calendar of the project. Will cause the schedule to be updated - returns a Promise

Suspend propagation processing. When propagation is suspended, calls to propagate do not proceed, instead a propagate call is deferred until a matching resumePropagate is called.