Assign multiple resources (equipment) to a single task

[ChristianM]

Hi,

We run a self-hosted SoPlanning (v1.56.01) to schedule field measurement jobs. A typical task - for example a clean-gas measurement - needs several pieces of equipment at the same time: 2 FID analysers, 1 NO/CO analyser, and often gas cylinders and other equipment.

At the moment a task ("periode") can be linked to only one resource (ressource_id), whereas the user field already supports multiple selection. That leaves us two workarounds, both unsatisfying:

- one separate task per device - clutters the planning and makes it hard to keep dates/status in sync;
- modelling the devices as users instead of resources - multi-select works, but then the "by resource" planning view and reporting no longer reflect equipment, and the staff list gets mixed with hardware.

Would it be possible to make the resource field multi-select as well, i.e. allow several resources per task, each shown on its own row in the "by resource" view - analogous to how multiple users already work?

Questions:
1. Is anything like this on the roadmap?
2. Has another user already implemented it as a patch/fork?

If we end up implementing it ourselves on a test instance, we are happy to contribute the patch back.

Thanks for the great tool.

[soplanning]

Hello
Sorry it's not yet possible.

It's on our todolist, so it could be delivered by the end of the year, more or less, no fixed date.

The next release in september will mostly concern the mobile app, newly added to soplanning (only for subscribing users).
best regards

[ChristianM]

Thanks for the reply, and good to hear it's already on the roadmap.

In the meantime we needed it, so we prototyped it on a copy of our
instance (1.56.01) - built as an opt-in feature so nothing changes for
existing installs until an admin turns it on. Posting the approach here in
case it's useful as a starting point or just to compare notes; use, adapt
or ignore as you see fit.

- new option SOPLANNING_OPTION_RESSOURCES_MULTIPLE (default off), shown in
the Configuration screen under "Resources management"
- new junction table planning_periode_ressource, back-filled from
planning_periode.ressource_id by a sql/update/update-1-56-02.txt migration
- planning_periode.ressource_id is kept as a denormalised "primary
resource" pointer, so the REST API, CSV/PDF/XLS/Gantt exports, iCal and
the notification e-mails keep working untouched
- the task form becomes a multi-select; the "by resource" planning view
shows a task on every one of its resource rows; the resource filter, the
exclusive-resource booking-conflict check and drag-and-drop move/copy
are all junction-aware

About 200 lines across 13 files, 7 commits on top of the 1.56.01 tag, with
a short design / migration / testing / notes doc set. Tested on a
production snapshot: create/edit/reopen, by-resource grid, filtering,
conflict detection, move/copy, resource deletion, and a full "option off =
unchanged" regression.

Happy to send it over as a patch series or a branch if that would help -
just let me know the preferred channel. And if you'd rather have it
always-on when resources are enabled (no separate option), that's an easy
change.

best regards

[ChristianM]

Small update: we've now put this on our live instance as a real-world
test of the approach - still v1.56.01, opt-in, currently switched off.

How we deployed it without touching the version mechanism:

- the 13 changed files copied over the pristine 1.56.01 files (originals
kept as .pre-multiresource)
- version.txt and planning_config.CURRENT_VERSION left at 1.56.01, and the
sql/update/update-1-56-02.txt file deliberately NOT shipped to the live
instance - so whenever an official 1.56.x / 1.57 update comes, your
migrations still run normally from where they left off
- instead the migration was run once by hand: create planning_periode_
ressource (+ FKs), back-fill it from planning_periode.ressource_id, add
the SOPLANNING_OPTION_RESSOURCES_MULTIPLE = 0 config row

With the option off, behaviour is identical to stock - login, planning,
task form, exports, all unchanged, no PHP notices. We'll switch it on for
real scheduling over the next days and report back with any rough edges.

Still happy to hand over the patch series or a branch whenever it's useful
to you.