[Canonical page](<https://docs.dhtmlx.com/planning-engine/rust/live-projects/editing-a-project/>)
[Full documentation index](<https://docs.dhtmlx.com/planning-engine/llms.txt>)


# Data Updates

This guide covers how to change a live [`Project`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md>) as the user works: adding, updating and removing tasks, links, resources and assignments, rescheduling after the edit, and recovering when part of an edit is refused.

## How editing works

A [`Project`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md>) holds one accepted state: the data from the last [`solve(Some(data), ..)`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#solve>) plus every edit since, with the dates the last solve accepted. You don't send the whole plan again for each change. You describe the change as a [`SchedulingChanges`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/scheduling-changes.md>) value and pass it to [`Project::apply`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#apply>).

Editing happens in two steps, and they're separate calls:

1. `apply(&changes)` writes the edit into the accepted state and marks the project unsolved. It doesn't schedule anything.
2. `solve(None, &options)` schedules the edited state, accepts the new dates and returns what moved.

Between the two calls the project has no baseline. `preview`, `load_profile`, `evaluate`, `suggest_assignments` and `roster` fail with [`ProjectError::NoBaseline`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/errors/project-error.md>) until you solve. You can call `apply` several times before one `solve`. The edits accumulate.

`apply` accepts what it can. Each operation in the change set either applies or is rejected on its own. A rejection isn't an `Err`: it's listed in the returned [`ApplyReport`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/apply-report.md>), and it sets `needs_resync`. From then on the project refuses `solve(None, ..)`, `apply` and `level` with `ProjectError::NeedsResync`. Your model and the project's state may now disagree, and the only way back is to send the full data with `solve(Some(data), ..)`.

`Err` from `apply` itself means the call didn't fit the project's state: `NeedsResync` from an earlier rejection, or `StaleBaseline` when the change set names a baseline that isn't current anymore. In both cases nothing was applied. See [Error handling](<https://docs.dhtmlx.com/planning-engine/rust/error-handling.md>).

## Change sets

A [`SchedulingChanges`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/scheduling-changes.md>) groups the edits by record kind. Each group is a [`Changes<A, U>`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/changes.md>) with three lists: `add`, `update` and `remove`.

| Group | `add` | `update` | `remove` |
|---|---|---|---|
| `tasks` | [`TaskData`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/data/task-data.md>) | [`TaskUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/task-update.md>) | task [`Id`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/data/id.md>) |
| `links` | [`LinkAdd`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/link-add.md>) | [`LinkUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/link-update.md>) | link `Id` |
| `resources` | [`ResourceData`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/data/resource-data.md>) | [`ResourceUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/resource-update.md>) | resource `Id` |
| `assignments` | [`AssignmentData`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/data/assignment-data.md>) | [`AssignmentUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/assignment-update.md>) | assignment `Id` |

Additions use the same record types as [`ProjectData`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/data/project-data.md>), except links: `LinkAdd` has an optional `id`. Leave a link or assignment id as `None` and [`apply`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#apply>) generates one (`$generated_link_1`, `$generated_assignment_1`, ...). Generated ids come back in `ApplyReport.effects`, so you can store them in your model.

```rust
use plen_core::{
    DateTime, LinkAdd, LinkData, LinkType, Patch, Project, ProjectData, SchedulingChanges,
    SolveOptions, TaskData, TaskUpdate,
};

fn task(id: i32, start: DateTime, duration: f64) -> TaskData {
    let mut task = TaskData::new(id);
    task.start_date = Some(start);
    task.duration = Some(duration);
    task
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let monday = DateTime::from_ymd_hm(2026, 8, 10, 8, 0).ok_or("invalid date")?;
    let data = ProjectData {
        tasks: vec![task(1, monday, 2.0), task(2, monday, 3.0)],
        links: vec![LinkData {
            id: 1.into(),
            source: 1.into(),
            target: 2.into(),
            link_type: LinkType::Fs,
            lag: 0.0,
            lag_unit: None,
        }],
        ..Default::default()
    };
    let mut project = Project::default();
    let options = SolveOptions::default();
    project.solve(Some(data), &options)?;

    let mut changes = SchedulingChanges::default();
    // A new task, linked after task 2. The link has no id: apply generates one.
    changes.tasks.add.push(task(3, monday, 1.0));
    changes.links.add.push(LinkAdd {
        id: None,
        source: 2.into(),
        target: 3.into(),
        link_type: LinkType::Fs,
        lag: 0.0,
        lag_unit: None,
    });
    // Task 1 now takes three days.
    let mut longer = TaskUpdate::new(1);
    longer.duration = Patch::Value(3.0);
    changes.tasks.update.push(longer);

    let report = project.apply(&changes)?;
    for op in &report.applied {
        println!("applied {}", op.path);
    }
    println!("generated links: {:?}", report.effects.generated_links);

    let result = project.solve(None, &options)?;
    for update in &result.updates {
        if let (Some(start), Some(end)) = (update.start_date, update.end_date) {
            println!("task {}: {start} .. {end}", update.id);
        }
    }
    Ok(())
}
```

The report lists `tasks.add[0]`, `tasks.update[0]` and `links.add[0]`, and the new link is `$generated_link_1`. After the solve, task 1 runs until `2026-08-13 08:00`, task 2 moves to `2026-08-13 08:00 .. 2026-08-18 08:00`, and task 3 starts when task 2 ends.

Operations don't run in the order you pushed them. `apply` runs them in a fixed order, so every reference comes after the adds it may need and every removal comes before the edits it could break:

1. tasks: remove, add, update
2. links: remove, update, add
3. resources: remove, add, update
4. assignments: remove, update, add

An operation is named by its group, list and index, such as `tasks.update[0]`. The same path shows up in `ApplyReport.applied` and `ApplyReport.rejected`.

## Update records and Patch

Update records ([`TaskUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/task-update.md>), [`LinkUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/link-update.md>), [`ResourceUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/resource-update.md>), [`AssignmentUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/assignment-update.md>)) name the record by `id` and carry every other field as a [`Patch<T>`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/patch.md>). A patch has three states:

- `Patch::Missing` (the default) leaves the field as it is.
- `Patch::Value(v)` sets it.
- `Patch::Null` clears an optional field, or restores the default of a field that always has a value: `auto_scheduling` goes back to `true`, `unscheduled` to `false`, `progress` to `0`, `priority` to `500`, `leveling_delay` to `0`, `pauses` to empty, `link_type` to FS and `lag` to `0`.

[`TaskUpdate::new(id)`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/task-update.md#new>) and the other `new` constructors set every field to `Missing`, so you only touch the fields you mean to change.

```rust
use plen_core::{
    ConstraintType, DateTime, Patch, Project, ProjectData, SchedulingChanges, SchedulingConfig,
    SolveOptions, TaskData, TaskUpdate,
};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let monday = DateTime::from_ymd_hm(2026, 8, 10, 8, 0).ok_or("invalid date")?;
    let thursday = DateTime::from_ymd_hm(2026, 8, 13, 8, 0).ok_or("invalid date")?;

    let mut review = TaskData::new("review");
    review.start_date = Some(monday);
    review.duration = Some(1.0);

    let data = ProjectData {
        config: SchedulingConfig {
            apply_constraints: true,
            ..Default::default()
        },
        tasks: vec![review],
        ..Default::default()
    };
    let mut project = Project::default();
    let options = SolveOptions::default();
    project.solve(Some(data), &options)?;

    // Value sets a field: "start no earlier than Thursday".
    let mut pin = TaskUpdate::new("review");
    pin.constraint_type = Patch::Value(ConstraintType::Snet);
    pin.constraint_date = Patch::Value(thursday);
    let mut changes = SchedulingChanges::default();
    changes.tasks.update.push(pin);
    project.apply(&changes)?;
    for update in &project.solve(None, &options)?.updates {
        if let Some(start) = update.start_date {
            println!("pinned: {} starts {start}", update.id);
        }
    }

    // Null clears the constraint; start_date moves the task back.
    // Every field left Missing keeps its value.
    let mut unpin = TaskUpdate::new("review");
    unpin.constraint_type = Patch::Null;
    unpin.constraint_date = Patch::Null;
    unpin.start_date = Patch::Value(monday);
    let mut changes = SchedulingChanges::default();
    changes.tasks.update.push(unpin);
    project.apply(&changes)?;
    for update in &project.solve(None, &options)?.updates {
        if let Some(start) = update.start_date {
            println!("unpinned: {} starts {start}", update.id);
        }
    }
    Ok(())
}
```

The first solve moves the task to `2026-08-13 08:00`. The second puts it back on Monday. Clearing the constraint alone wouldn't do that: the accepted state already holds the Thursday dates, so the update also sets `start_date`.

### Which dates a task update keeps

A task has three linked date fields: `start_date`, `end_date` and `duration`. When an update sets some of them, [`apply`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#apply>) keeps what you sent and derives the rest:

- `start_date` alone keeps the duration and recomputes the end (a drag).
- `end_date` alone keeps the start and recomputes the duration (a resize from the right edge).
- `duration` alone keeps the start and recomputes the end.
- `start_date` and `end_date` together recompute the duration.
- A new `calendar_id`, or a new `parent` while calendars are inherited ([`CalendarMode::TaskInherited`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/data/calendar-mode.md>)), keeps the start and duration and recomputes the end on the new calendar. Under an inherited calendar, the descendants that inherit it re-derive their ends too.

An explicit `start_date` that falls on non-working time is kept as sent when the task has no predecessor. The end is computed forward from it on the working calendar, so only the start sits outside working time. Snap the date in your UI if you don't want that.

### Feeding results back

A [`Mutation`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/results/mutation.md>) from a result uses the same field names as [`TaskUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/task-update.md>), so a result entry maps field by field onto an update. That's useful when you want to commit dates you got from [`preview`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#preview>) or a leveled clone:

```rust
use plen_core::{Mutation, Patch, TaskUpdate};

fn patch<T: Clone>(value: &Option<T>) -> Patch<T> {
    match value {
        Some(value) => Patch::Value(value.clone()),
        None => Patch::Missing,
    }
}

fn to_update(mutation: &Mutation) -> TaskUpdate {
    let mut update = TaskUpdate::new(mutation.id.clone());
    update.start_date = patch(&mutation.start_date);
    update.end_date = patch(&mutation.end_date);
    update.duration = patch(&mutation.duration);
    update.leveling_delay = patch(&mutation.leveling_delay);
    update.pauses = patch(&mutation.pauses);
    update
}
```

`pauses` replaces the whole list. Set it to `Patch::Value(vec![])` or [`Patch::Null`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/patch.md>) to remove every pause. See [Clear leveling](<https://docs.dhtmlx.com/planning-engine/rust/how-to/clear-leveling.md>).

## Applying

[`apply`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#apply>) returns an [`ApplyReport`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/apply-report.md>):

- `applied` lists the path of every accepted operation.
- `rejected` lists the path and message of every refused one.
- `effects` lists what the edit changed beyond the records you named (below).
- `needs_resync` is `true` when anything was rejected.
- `revision` is the project's revision number after this edit.

Removals cascade, and `effects` tells you what went with them. Removing a task removes its descendants, every link that touches any of them and every assignment on them. Removing a resource removes its assignments.

```rust
use plen_core::{
    AssignmentData, DateTime, LinkData, LinkType, Project, ProjectData, ResourceData,
    SchedulingChanges, SolveOptions, TaskData, TaskType,
};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let monday = DateTime::from_ymd_hm(2026, 8, 10, 8, 0).ok_or("invalid date")?;
    let mut phase = TaskData::new("phase");
    phase.task_type = TaskType::Summary;
    let mut spec = TaskData::new("spec");
    spec.parent = Some("phase".into());
    spec.start_date = Some(monday);
    spec.duration = Some(2.0);
    let mut release = TaskData::new("release");
    release.start_date = Some(monday);
    release.duration = Some(1.0);

    let data = ProjectData {
        tasks: vec![phase, spec, release],
        links: vec![LinkData {
            id: "spec-release".into(),
            source: "spec".into(),
            target: "release".into(),
            link_type: LinkType::Fs,
            lag: 0.0,
            lag_unit: None,
        }],
        resources: vec![ResourceData {
            id: "ann".into(),
            capacity: None,
            calendar_id: None,
        }],
        assignments: vec![AssignmentData {
            id: Some("ann-spec".into()),
            task: "spec".into(),
            resource: "ann".into(),
            value: 1.0,
            offset: None,
            duration: None,
        }],
        ..Default::default()
    };
    let mut project = Project::default();
    project.solve(Some(data), &SolveOptions::default())?;

    let mut changes = SchedulingChanges::default();
    changes.tasks.remove.push("phase".into());
    let report = project.apply(&changes)?;

    let effects = &report.effects;
    println!("tasks: {:?}", effects.removed_tasks);
    println!("links: {:?}", effects.removed_links);
    println!("assignments: {:?}", effects.removed_assignments);
    Ok(())
}
```

Removing the summary `phase` also removes `spec`, the link `spec-release` and the assignment `ann-spec`. Delete the same records from your own model.

The other `effects` lists:

- `generated_links` and `generated_assignments` hold the ids `apply` made up for additions without one.
- `dropped_links` and `dropped_assignments` hold records that were accepted but are now inactive, for example a link to an unscheduled task. They stay in the project and come back into play when the task does.

`apply` takes `&mut self` and edits the project in place. Clones made earlier don't see the edit, so you can clone a project, apply a multi-step edit to the clone and drop it if the user cancels. For a single edit, [`preview`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#preview>) does the same job without a clone. See [Previewing changes](<https://docs.dhtmlx.com/planning-engine/rust/live-projects/previewing-changes.md>).

Field-only task edits and assignment updates take a fast path that patches the affected records without rebuilding the whole model. Frequent small edits, like drags, stay cheap.

## Rescheduling

After [`apply`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#apply>), call [`solve(None, &options)`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#solve>). It schedules the edited state, accepts the dates as the new baseline and returns the updates relative to the previous one.

Tasks that a successful operation added or updated are always reported, even when the planner leaves them exactly where the edit put them. The same goes for tasks whose working calendars changed because of a resource or assignment edit. Your model gets the derived end or duration for every task you edited, not only for the ones that moved. These reported tasks accumulate across several `apply` calls until the next acyclic `solve(None, ..)` or `level`. A cyclic solve keeps them pending.

### Guarding against stale edits

A UI usually edits the dates it showed the user. If the project changed in between (another edit from another tab, a leveling run), applying the edit can do the wrong thing. Set `SchedulingChanges.baseline_id` to the token of the result the user saw, and [`apply`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#apply>) refuses the whole change set with `StaleBaseline` when that token isn't current.

```rust
use plen_core::{
    DateTime, Error, Patch, Project, ProjectData, ProjectError, SchedulingChanges, SolveOptions,
    TaskData, TaskUpdate,
};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let monday = DateTime::from_ymd_hm(2026, 8, 10, 8, 0).ok_or("invalid date")?;
    let mut design = TaskData::new(1);
    design.start_date = Some(monday);
    design.duration = Some(2.0);

    let mut project = Project::default();
    let options = SolveOptions::default();
    let loaded = project.solve(
        Some(ProjectData {
            tasks: vec![design],
            ..Default::default()
        }),
        &options,
    )?;
    let seen = loaded.baseline_id.clone();

    // The edit was made against the dates the user saw.
    let mut changes = SchedulingChanges {
        baseline_id: seen.clone(),
        ..Default::default()
    };
    let mut longer = TaskUpdate::new(1);
    longer.duration = Patch::Value(3.0);
    changes.tasks.update.push(longer);
    project.apply(&changes)?;

    // A second edit still carrying the old token is refused as a whole.
    match project.apply(&changes) {
        Err(Error::Project(ProjectError::StaleBaseline)) => println!("stale: reload first"),
        other => println!("unexpected: {other:?}"),
    }

    let solved = project.solve(None, &options)?;
    println!("new baseline differs: {}", solved.baseline_id != seen);
    Ok(())
}
```

A token names a baseline only while the project is solved and clean. After an `apply`, any `baseline_id` is stale until the next solve, so take a fresh token from each result. Tokens are opaque: don't store them or compare them across runs. `None` (the default) skips the check.

## Rejections and resync

An operation is rejected when it can't apply: an unknown id in `update` or `remove`, a duplicate id in `add`, [`Patch::Null`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/patch.md>) on a required field (a link's `source` or `target`, an assignment's `task`, `resource` or `value`), or a record that fails validation after the edit, such as an invalid pause or assignment slice. Each operation is tried on its own copy, so a rejected operation leaves no partial edit behind, and the operations around it still apply.

```rust
use plen_core::{
    DateTime, Error, Patch, Project, ProjectData, ProjectError, SchedulingChanges, SolveOptions,
    TaskData, TaskUpdate,
};

fn load() -> Result<ProjectData, Box<dyn std::error::Error>> {
    let monday = DateTime::from_ymd_hm(2026, 8, 10, 8, 0).ok_or("invalid date")?;
    let mut design = TaskData::new("design");
    design.start_date = Some(monday);
    design.duration = Some(2.0);
    Ok(ProjectData {
        tasks: vec![design],
        ..Default::default()
    })
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut project = Project::default();
    let options = SolveOptions::default();
    project.solve(Some(load()?), &options)?;

    let mut changes = SchedulingChanges::default();
    changes.tasks.remove.push("deleted-elsewhere".into());
    let mut longer = TaskUpdate::new("design");
    longer.duration = Patch::Value(4.0);
    changes.tasks.update.push(longer);

    let report = project.apply(&changes)?;
    for op in &report.applied {
        println!("applied {}", op.path);
    }
    for op in &report.rejected {
        println!("rejected {}: {}", op.path, op.message);
    }

    if report.needs_resync {
        // solve(None) and apply now fail until the full data is sent again.
        if let Err(Error::Project(ProjectError::NeedsResync)) = project.solve(None, &options) {
            project.solve(Some(load()?), &options)?;
        }
    }
    Ok(())
}
```

The update applies and the removal is rejected with `rejected tasks.remove[0]: unknown task id`. The project now holds the update but not the removal, which is probably not what your model holds. That's why any rejection blocks further edits: `solve(None, ..)`, `apply` and `level` return [`ProjectError::NeedsResync`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/errors/project-error.md>) until a successful `solve(Some(data), ..)` replaces the whole state with data you know is right.

The resync data must pass validation. If it doesn't, you get [`Error::Input`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/errors/error.md>), and the project still needs a resync. See [Recover from rejected changes](<https://docs.dhtmlx.com/planning-engine/rust/how-to/recover-from-rejected-changes.md>).

[`evaluate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#evaluate>) and [`suggest_assignments`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#suggest_assignments>) use the same apply on disposable copies, so a rejected candidate shows up as its `CandidateResult.error` (a [`RejectedOperation`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/rejected-operation.md>)) instead of blocking the project. See [Evaluating alternatives](<https://docs.dhtmlx.com/planning-engine/rust/resources-and-assignment/evaluating-alternatives.md>).

## What change sets can't do

Some edits have no operation. For these, rebuild the data in your model and send it with [`solve(Some(data), ..)`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#solve>):

- Calendars can't be added, changed or removed. Tasks and resources can switch to another existing calendar through `calendar_id`.
- [`SchedulingConfig`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/data/scheduling-config.md>) can't change: duration unit, `use_calendars`, `calendar_mode`, `apply_constraints` and the other settings are fixed until the next full solve.
- A task's `task_type` and `duration_unit` aren't in [`TaskUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/task-update.md>). To turn a task into a summary or a milestone, remove it and add it again (its links and assignments go with the removal), or resync.
- An id can't be renamed. `update` finds the record by its id and never changes it.
- [`ResourceUpdate`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/changes/resource-update.md>) changes only `capacity` and `calendar_id`.

Calls that don't need a change set also don't use one. [`level`](<https://docs.dhtmlx.com/planning-engine/rust/api/core/project/project.md#level>) writes its own `leveling_delay` and `pauses` edits and accepts the result. See [Leveling resources](<https://docs.dhtmlx.com/planning-engine/rust/resources-and-assignment/leveling-resources.md>).