Feedback wanted: Restricting where jobs can be moved in the WebUI Gantt Chart (v2)

Hi everyone,

A request we hear from several teams is a way to control where Users can move jobs in the WebUI Gantt Chart. In many planning apps, not every job belongs on every resource. A job may need a machine with the right capability, or an event on a tank may move to other tanks but never to a ship or pipeline row.

Today the only per-job control comes from the data itself: a readonly flag set through the webui::FlagsIdentifier annotation on the identifiers behind the chart. It's all or nothing. A job is either fully editable, including moving it to any other resource, or not editable at all, not even in time. To enforce anything in between, apps use an UponChange procedure that reverts forbidden moves after the drop. That works, but the user drops the job, it jumps back, and they get a message without knowing where the job can go.

We're designing an option for the Gantt Chart (v2) that stops these moves before they happen, and we'd like your feedback before we build it. Below is what we have in mind, with a few questions at the end. Answers to any of them help, even one or two.

A new option: Allowed Resource Placement

The option takes a binary parameter over the chart's resource and job indices. For each combination, it says whether that job may be placed on that resource:

                Machine A   Machine B   Machine C
Job 1               1           1           0
Job 2               1           0           0
Job 3               0           1           1

• 1 means the job may be on that resource.
• 0, or no value, means it may not.
• Option not set means no restrictions, exactly as today.

The parameter can have extra indices, for example a scenario index. You slice those like any other identifier. After slicing, its indices must match the chart's resource and job indices.

You'll usually define it once in the model from data you already have. For example:

! Jobs may only go on resources that can handle their type
bpAllowedPlacement(iResource, iJob) := bpCanHandle(iResource, epJobType(iJob));

! Jobs may move in time, but never change resource
bpAllowedPlacement(iResource, iJob) := (iResource = epJobResource(iJob));

The rule

An edit is allowed only if the job ends up on a resource where its placement is 1.

This applies to every way of editing a job in the chart:

What users see

Single job. While dragging over a row where the job isn't allowed, the pointer shows a not-allowed cursor and the row is shown as unavailable. Letting go there does nothing. The job stays where it was, with no jump back, no message, and no call to the model. The user can't make the mistake in the first place.

Several selected jobs. It's all or nothing. If even one selected job isn't allowed where the group would end up, none of them move. Because the cursor alone can't tell you which job is the problem, a warning names it:

Can't move 3 jobs to Machine C
Job 1 isn't allowed on Machine C, so none of the selected jobs were moved. Deselect Job 1 or choose another resource.

What it does not do

This is an interaction rule, not a data rule. The option only limits what End Users can do by dragging and resizing in the chart. It never checks data coming from your model:

• If a solve or procedure puts a job on a resource where its placement is 0, the chart shows it there as usual.
• That job can't be moved in time or resized on that row, but it can be dragged to a row where it is allowed.
• Once moved away, it can't be dragged back.

How it works with what's already there

• The readonly flag always wins. A job flagged readonly can't be edited, whatever its placement says.
• Your model stays in charge. If the chart allows a move but the identifier's domain condition rejects it, you get the existing rejection message, and the job stays where it was.
• Configuration errors stop the chart. If the indices don't match the chart's after slicing, the chart doesn't load and shows a message, like other misconfigured options.

Out of scope

• Restrictions on edits made through other widgets (for example, a table on the same identifiers) or in procedures
• A single widget-level switch. The same effect is one line in the model, as in the example above.
• Time-window limits (earliest start or latest end per job)
• Suggesting an alternative allowed resource when a drop is blocked
• Highlighting jobs whose current position conflicts with the placement rules

Help us prioritize

We're also designing a Horizontal navigator for the Gantt Chart (v2), described in this post. Both features are candidates for the same upcoming development cycle, so your view on which matters more to your users directly helps us decide what comes first.

Your feedback

Whether you build apps with the Gantt, use them day to day, or are just curious, we'd like to hear from you. Please share your thoughts on any of these questions:

1. Do you have rules today about which jobs may go on which resources? How do you enforce them now (UponChange, readonly flags, something else)?
2. Does a job × resource binary parameter fit how your model describes these rules?
3. Is the rule "an edit is allowed only if the job ends up on an allowed resource" what you'd expect? Take this example: a solve puts Job 2 on Machine B, where its placement is 0. With this rule:
   • Job 2 can't be moved in time or resized on Machine B, because it would still end up on a resource where it isn't allowed.
   • Job 2 can be dragged to Machine A, where it is allowed.
   • Once on Machine A, it can't be dragged back to Machine B.
   • Does that match what your users would expect? Or should a job on a resource where it isn't allowed still be editable in time there, so that only moving it to such a resource is blocked?
4. Is not-allowed cursor plus no drop, with no message, enough feedback for a single job?
5. For multi-select, do you agree with all-or-nothing, or should the allowed jobs move and only the blocked ones stay?
6. Is it right that the option never checks data from the model, and only restricts what users do in the chart?
7. Should the readonly flag always take precedence over placement?
8. Do you need restrictions on other edits, such as time windows, as well? (We're collecting those separately.)
9. Any other cases where moving or resizing jobs should behave differently?
10. If you could have only one of these first, which would it be: Allowed Resource Placement or the Horizontal navigator? What makes it the more important one for your users?

Thanks,
Madhu Krishnappa
AIMMS WebUI Product Owner