Projects

Move tasks between projects

dolixtaches · version 1.0.3

A task was created in the wrong project: you move it, with its subtasks, its time spent and its documents.

Price: €49 excl. VAT
Dolibarr: 19.0 minimum
Version: 1.0.3
Licence: GPL v3+
Languages: French, English

€49 excl. VAT.

Ordering, payment, invoicing and download are handled by the DoliStore.

Buy on the DoliStore — €49 excl. VAT

Main screen on Dolibarr 24.0.0: the source project “CH-001 - Installation du poste de contrôle”, the target project “PJ2609-0005 - Mise à niveau du réseau interne”, the banner “5 tâche(s) dans le projet « CH-001 ».” (5 task(s) in project ‘CH-001’.), then the five tasks with their hierarchy — T-011 and T-012 indented under T-010 — each showing “CH-001” struck through followed by “PJ2609-0005” in green. Screenshot of the French-language interface.

What the module does

You choose a source project and a target project; the module lists the tasks of the source project with their hierarchy, subtasks indented under their parent.
Preview before writing: each row shows the source project struck through followed by the target project in green, and you tick the tasks one by one, or all at once.
Subtasks follow their parent task without you having to tick them. A task whose parent stays in the source project becomes a top-level task.
Time spent and assignees follow the task: they are recorded on the task itself and not on the project, so nothing needs to be re-entered.
Attached documents are moved to the target project's folder. A setting lets you leave them where they are.
Transactional move: at the first error, no task is moved. A move history can be viewed on the module setup page.

Who it is for

A task was opened under the wrong project, and Dolibarr cannot move it: you have to recreate it by hand and lose the time already logged, or clone it and keep a duplicate.

The project is open, the tasks are entered, the hours are logged. Then someone notices that three of them should never have been there: they belong to the job next door, or to the project that was created the following week to keep things properly separate.

Dolibarr cannot move them. On a task card, the project is shown as a plain link — in view mode as in edit mode, there is no drop-down list to change it. The only related action is Clone, which recreates the task in the same project.

That leaves two bad options. Recreate the task by hand in the right project, and lose the time already entered, the assignees and the attached files. Or clone it, and live with a duplicate where nobody will know any more which of the two is the real one.

The need is known and it is public: issue #23230 in the Dolibarr repository, “Move a task to another project”, opened on 14 December 2022, asks for exactly that: a project drop-down list on the task card. It is still open.

Who it is for: Any organisation that tracks its work by project and logs time on tasks: engineering consultancies, agencies, service companies, tradespeople who open one project per job. The need arises the day a task has been opened under the wrong project and hours have already been entered on it.

What the module does not do

This section appears on all 12 module pages, without exception.

Only moves tasks, and only from one project to another. Does not move a project, does not merge two projects, does not rename anything and does not change the reference of the tasks.
The move is written directly to the database: Dolibarr triggers are not run and no event is created in the agenda. Each task moved is, however, recorded in the Dolibarr logs and in the module history.
The screen lists all the tasks of the source project, with no pagination, no search and no safety cap. On a project with several hundred tasks, the page is long.
Moving the files is not covered by the rollback. The transaction protects the tasks and the history; a folder already moved on disk stays moved even if a later task fails. And if a folder with the same name already exists in the target project, the files stay where they are with no message to say so — the “Documents moved” counter in the final message simply does not count them.
The files are moved on disk, but the Dolibarr document index is not updated: it keeps the old path. The task's “Documents” tab, which reads the disk, shows the files normally.
A task's visibility follows that of its project, in Dolibarr as in the module. A task moved to a project that a user is not allowed to see disappears from their lists. You yourself can only move between projects that you can see.
No automatic undo: the history says what was moved, it does not undo it. To go back, you make the move again in the other direction.
The module does not check that the two projects belong to the same third party, and time already invoiced follows the task, keeping its link to the invoice. A move to another customer's project is possible: it is up to you to know what you are doing.

How it works

The module adds a screen under ProjectsMove tasks. There you choose a source project and a target project, and it lists the tasks of the source project with their hierarchy, subtasks indented under their parent.

Each row already shows the result: the source project struck through, then the target project in green. You tick the tasks to move, one by one or all at once, and you confirm. A confirmation window reminds you of what will move with the task.

Nothing is written before that confirmation. The preview screen only reads.

The move itself is done in a transaction. If a single task fails, the whole operation is cancelled: no task has changed project, and a message says so.

This is the heart of the matter, and it deserves some detail, because half of what moves with the task does so without the module having to touch it.

	Moves with the task	How
Subtasks	yes	The module extends your selection: ticking a task implicitly ticks all its descendants. A subtask is never left behind by its parent.
Time spent	yes	Time entries are recorded on the task, not on the project. Nothing to re-enter, nothing to recalculate.
Assignees	yes	Assignments are attached to the task, like time spent.
Tags/categories and complementary attributes	yes	Also attached to the task.
Attached documents	yes, and it is a real move	The task’s file folder is moved from the source project’s folder to the target project’s folder. It is the only item in this list that the module actually moves, and the only one you can switch off in the settings.

When the parent task stays behind. If you move a subtask without moving its parent, the subtask becomes a top-level task in the target project: the parent link cannot span two projects. The screen says so below the table, before you confirm.

The screen fits on one page.

At the top, the “1. Which projects?” block with the two drop-down lists, Source project and Target project. The Show tasks button opens the table, preceded by a banner such as “5 task(s) in project ‘CH-001’.”.

The table has four useful columns — Ref., Label, Progress and Project — and one checkbox per row, plus a checkbox in the header that ticks everything. The Project column is the preview: CH-001 struck through, an arrow, PJ2609-0005 in bold green.

In the screenshot, five tasks from project CH-001 are ready to go to PJ2609-0005, and the hierarchy is visible: T-011 and T-012 are indented under T-010, of which they are subtasks.

Below the table, the reminder about subtasks, then the Move the ticked tasks button.

The setup page holds the two settings and, below them, the table of moves already made: date, user, clickable task, source project, target project, and a tick in the Documents column when files were moved.

The module sits in the Projects menu. You choose the source project and the target project, then tick row by row: each task already shows where it is going. Screenshot of the French-language interface.

At the end, the module says what it did: how many tasks were moved, and for how many of them the attached documents followed. Screenshot of the French-language interface.

The “Documents” column ticks the tasks whose attached files were moved with them. Screenshot of the French-language interface.

After the move, the tasks are in the target project — hierarchy, workload and time spent included. Screenshot of the French-language interface.

Settings

Two settings, on the module setup page. Both are switched on at installation.

Setting	Default	Effect
Move the documents too	on	Moves the task’s attachment folder into the target project’s folder. Unticked, the files stay where they are and only the task changes project.
Keep a move history	on	Records every move: date, user, task, source project, target project, and whether the documents followed.

The history can be viewed on the same page, below the settings. It cannot be purged from the screen.

Setup page on Dolibarr 24.0.0: the two settings, “Déplacer aussi les documents” (Move the documents too) and “Conserver un historique des déplacements” (Keep a move history), both ticked, and the history table — four moves, T-010 to T-013, from “CH-001” to “PJ2609-0005”. Screenshot of the French-language interface.

The two settings, and the move history: which task, from which project to which other, by whom, when — and whether its documents followed. Screenshot of the French-language interface.

Security and safeguards

The preview is read-only. Nothing can be written without ticking, clicking and confirming.
A dedicated permission, “Use task moving”. Without it, neither the menu nor the screen.
Dolibarr’s standard permissions on top: the screen requires the read permission on projects, and the move requires the create/modify permission on projects.
The core visibility rules are respected. If you are not allowed to read all projects, the module relies on the Dolibarr function that determines the authorised projects — public projects, projects of which you are a contact — and on the restriction applied to external users, an account linked to a third party never being offered a project linked to another third party.
Server-side re-checking: the project identifiers sent by the form are never taken on trust. Both projects are read again within your scope before anything is written, and a forged identifier results in access being refused.
The selection is bounded: only tasks actually present in the source project are kept, and each update restates the source project in its condition.
Multi-company: every query is filtered on the authorised entities.
Anti-CSRF token checked when the settings are saved, an empty token being refused outright.
Every task moved is written to the Dolibarr logs and to the module history.

What you get

What the module writes to your installation
Database tables created	One table: llx_dolixtaches_log. It records the move history (date, user, task identifier, its reference and label at the time of the move, source project, target project, flag for whether the documents were moved, entity). No business data is stored in it.
Permissions	One permission: “Use task moving”. Without this permission, the screen cannot be accessed and the menu does not appear. The screen also requires the Dolibarr read permission on projects, and the move itself requires the create/modify permission on projects.
Uninstalling	Disable the module in SetupModules/Applications. The menu and the permission disappear. Tasks already moved stay in their target project: they are data in your database, as if you had created them there. Documents already moved also stay in the target project's folder. The history table llx_dolixtaches_log and the module's two settings are not deleted. Nothing is erased from your database without your intervention.

One table is added: llx_dolixtaches_log. It holds only the move history — date, user, task, source and target projects, and a flag for whether the documents were moved. No business data is copied into it.
The only column changed in your data is the task’s project, and, for a task whose parent stays behind, its parent link. Nothing else is rewritten: not the label, the reference, the dates or the progress.
Moved files are moved inside the Dolibarr documents folder. Nothing is written outside that folder.
No outgoing connection: the module does not call any external server.

Compatibility

The module descriptor only declares a minimum version. No upper bound is written in the code: the versions below are those on which the module has actually been run.

Compatibility of the Move tasks between projects module
Dolibarr versions	Dolibarr 19.0 minimum. Installed and run on 19.0.4, 20.0.4, 21.0.4, 22.0.5, 23.0.4 and 24.0.0.
Minimum PHP	7.4
Dolibarr modules to enable	Projects
Licence	GPL v3 or later, full source code
Languages	French, English
Menu	Projects menu“Move tasks”.

Installation

Get the module from the DoliStore and download the zip file.
In Dolibarr: HomeSetupModules/Applications“Deploy/install external app/module” tab, then upload the zip. Otherwise, unzip the dolixtaches folder into htdocs/custom/.
The Projects module must be enabled: “Move tasks” depends on it and cannot be enabled without it.
Enable “Move tasks” in the module list. The history table is created at that point, and the two settings take their default value: documents moved, history kept.
Grant the “Use task moving” permission to the users concerned, in Users & Groups. To actually move a task, the same people need the Dolibarr create/modify permission on projects.
Check the two settings on the module setup page.
Back up the database and the documents folder before the first bulk move.

The details — permissions on the custom folder, shared hosting, upgrades, uninstalling — are on the page Installation and upgrades.

Frequently asked questions

Which Dolibarr versions does this module work on?

The descriptor requires Dolibarr 19.0 minimum and PHP 7.4 minimum. The module has been installed and run on 19.0.4, 20.0.4, 21.0.4, 22.0.5, 23.0.4 and 24.0.0, on MariaDB as well as on PostgreSQL. The screenshots on this page were taken on 24.0.0. No maximum version is set in the module.

Can Dolibarr really not move a task?

No. On a task card, the project is shown as a plain link, in view mode as in edit mode: there is no drop-down list to change it. Checked in the code of Dolibarr 19.0.4 and 24.0.0. The only related native action is “Clone”, which recreates the task in the same project — so a duplicate, not a move.

What moves with the task?

Its subtasks, its time spent, its assignees, its tags/categories and its complementary attributes: all of them are recorded on the task itself and not on the project, so they follow the move without the module having to touch them. Attached documents, on the other hand, are really moved from one folder to another on the server, and they are the only one of these items that you can switch off in the settings.

What happens if the operation fails halfway?

No task is moved: the updates and the history entries are made in a transaction, rolled back as a whole at the first error, and a message says so. One honest caveat: moving the files on disk is not covered by this rollback. A folder already moved stays moved.

What if I uninstall?

The menu and the permission disappear. Moved tasks stay in their target project and the documents in their new folder. The history table and the two settings remain in the database: you can delete them yourself if you wish.

Who provides support, and how do payment and updates work?

Support is provided by the person who wrote the module, at support@dolix.fr. Ordering, payment, the invoice and the download are handled by the DoliStore, where new versions are published; the version history on this page is updated with each release.

Version history

Taken from the module’s ChangeLog.md file: a single source.

1.0.310 September 2026

Display fix: after a successful move, the screen showed, below the success message, a warning that contradicted it, and a column in which the target project pointed to itself. The move itself was correct; only the final screen was misleading.

1.0.210 September 2026

Technical: the anti-CSRF token check function, until now named verifCsrfToken(), now has a name prefixed with the module's. A generic name declared by a module would prevent the page from opening if Dolibarr were to add a function with the same name. An empty token is also explicitly refused.

1.0.110 September 2026

Fix: the setup screen returned a 500 error on saving, because Dolibarr's settings-writing function was called without its library being loaded. Settings are now saved normally.

1.0.09 September 2026

First version: moving tasks from one project to another, with a beforeafter preview, row-by-row selection and explicit confirmation. Subtasks follow their parent task; a task whose parent stays behind becomes a top-level task. Time spent and assignees follow the task; attached documents are moved to the target project's folder, an option that can be switched off. Transactional move and move history. Dolibarr visibility rules and multi-company respected, identifiers re-checked on the server side. Dedicated setup page.