Dolibarr-Modul · doligitlab · MIT

DoliGitlab — Dolibarr and GitLab, bidirectionally interlocked.

Dolibarr ERP/CRM module with deep GitLab integration: issues ↔ tickets, time tracking, releases, wikis — all assigned per user, automated via triggers and cron. MIT licence, Dolibarr 20+, PHP 8+.

Repo öffnen →

Das Problem

When ERP and dev tooling don't know each other.

With DoliGitlab

Bidirectional issue/ticket sync with trigger-based updates and conflict resolution
Time tracking auto-synced (trigger Dolibarr → GitLab, cron GitLab → Dolibarr)
Release browser in the Dolibarr backend with download button (zip/tar.gz/assets)
Wiki viewer for GitLab project and group wikis directly in Dolibarr
User/group assignments — each user only sees what's been assigned

Until now

Tickets in Dolibarr, issues in GitLab — kept in sync by hand
Time tracking duplicated: once in the dev tool, once for invoicing
Releases for customers manually compiled for download
No central wiki access, no granular GitLab access per Dolibarr user

Four function blocks

Wiki viewer & granular assignment

GitLab project and group wikis are rendered directly in Dolibarr (Markdown support). Visibility follows user/group assignments — anyone without rights to a GitLab project sees neither issues, wiki, nor releases.

Time tracking & releases

Hours booked in Dolibarr land automatically on the linked GitLab issue (spent time + estimate). The release browser shows releases of all assigned GitLab projects with a download button and Markdown-rendered release notes.

Cron sync with auto-import

A configurable cron (5 min to 24h interval) syncs all existing mappings and can optionally import new GitLab issues into Dolibarr automatically. Status, last run, and output visible directly in the module settings.

Bidirectional issue/ticket sync

GitLab issues are imported as Dolibarr helpdesk tickets; changes flow back automatically (via Dolibarr trigger). A mapping table persists the link; sync status (synced/pending/conflict/error) is visible per issue.

Installation and setup

Install the module

cp -r doligitlab /path/to/dolibarr/htdocs/custom/doligitlab

Then in Dolibarr go to Home → Setup → Modules/Applications, search for “DoliGitlab” and enable it.

Configure the GitLab connection

Under Setup → Modules → DoliGitlab Setup:

GitLab instance URL without trailing slash (e.g. gitlab.example.com)
Personal access token with the api scope
Test the connection, then enable the sync options you want (Tasks, Time Tracking, Cron)

For production use we recommend a dedicated service account rather than a personal token.

Grant permissions

Under Users & Groups » [User] » Permissions:

doligitlab → read — view projects, groups, issues, wiki
doligitlab → write — manage user assignments
doligitlab → admin — access module configuration
doligitlab → releases → download — download release assets

Set up cron

Automatic synchronisation requires Dolibarr's cron system to be active. Add to system cron:

*/5 * * * * /usr/bin/php /path/to/dolibarr/htdocs/cron/cron_run_jobs.php securitykey=YOUR_CRON_KEY >/dev/null 2>&1

In DoliGitlab setup, then enable cron sync, choose a frequency (default 15 minutes) and optionally enable auto-import of new issues.

Requirements

Component	Version
Dolibarr	20.0 or higher
PHP	8.0 or higher, with cURL extension
GitLab	Any version with API v4
Access token	Personal access token with the `api` scope

Sync behaviour and conflicts

Bidirectional synchronisation reflects changes from both sides — some via Dolibarr triggers immediately, others via the cron run.

Event	Direction	Trigger
GitLab issue created	GL → DOL	Cron (auto-import) or manual
GitLab issue updated	GL → DOL	Cron or manual sync
Dolibarr ticket modified	DOL → GL	Automatic (Dolibarr trigger)
Dolibarr ticket closed	DOL → GL	Automatic (Dolibarr trigger)
Dolibarr ticket reopened	DOL → GL	Automatic (Dolibarr trigger)
Dolibarr ticket deleted	DOL → GL	Automatic (closes the GitLab issue)
Time logged in Dolibarr	DOL → GL	Automatic (Dolibarr trigger)
Time logged in GitLab	GL → DOL	Cron or manual sync

Conflict resolution

When both sides are modified between two sync runs, GitLab takes precedence by default. Conflicts are flagged in the sync map entry with status conflict and surfaced in the backend. A manual re-sync in the desired direction resolves the conflict.

Per-issue sync status

Every linked issue has a visible status: synced, pending_gl, pending_dol, conflict, error. The status sits in the mapping table llx_doligitlab_sync_map and is also visible in the sync overview in the backend.

Database, permissions, API

Database tables

The module creates two tables with the prefix llx_doligitlab_. Both are created automatically when the module is enabled.

llx_doligitlab_user_assignment — mapping between Dolibarr users and GitLab projects/groups. Fields: fk_user, gitlab_id, gitlab_type (project/group), gitlab_name, gitlab_path, gitlab_url, plus audit fields date_creation, fk_user_creat.

llx_doligitlab_sync_map — bidirectional sync state between GitLab issues and Dolibarr tickets/tasks. Fields include: gitlab_project_id, gitlab_issue_iid, dolibarr_type, dolibarr_id, last_gitlab_update, last_dolibarr_update, last_sync, sync_direction, sync_status.

GitLab API endpoints used

The module talks exclusively to the GitLab REST API v4. Overview of the endpoints used:

Area	Endpoints
Authentication	`GET /user`
Projects	`GET /projects`, `GET /projects/:id`, `GET /groups/:id/projects`
Groups	`GET /groups`, `GET /groups/:id`
Releases	`GET /projects/:id/releases`, `GET /projects/:id/releases/:tag`
Issues (read)	`GET /projects/:id/issues`, `GET /projects/:id/issues/:iid`, `GET /groups/:id/issues`
Issues (write)	`POST /projects/:id/issues`, `PUT /projects/:id/issues/:iid`
Time tracking	`GET /time_stats`, `POST /add_spent_time`, `POST /time_estimate`, `POST /reset_spent_time`
Wiki	`GET /projects/:id/wikis`, `GET /groups/:id/wikis`

Troubleshooting

Connection fails: check trailing slash in the GitLab URL, token scope api, firewall/DNS, PHP cURL enabled.
Cron not running: is the “Scheduled Jobs” module enabled? Is the system cron calling cron_run_jobs.php? Status in Setup → Scheduled Jobs, logs in documents/dolibarr.log.
Sync conflicts: GitLab wins by default. Conflicts are flagged in the sync map with conflict; a manual re-sync resolves them.
No projects visible: check user assignments (GitLab → Assignments), token access to the resources, doligitlab → read permission set.

Source code & repo

Licence & issues

MIT licence · Copyright Moselwal Digitalagentur GmbH 2026. Bug reports and pull requests via the relevant repo.

Dolibarr Marketplace

Currently not in the official Dolistore — install by copying directly into htdocs/custom.

GitHub mirror (if available)

If a public mirror exists: github.com/moselwal/doligitlab — placeholder, verify before publish.

github.com/moselwal/doligitlab

GitLab (source of truth)

Repository including code, issues, CI/CD, and release tags. Confirm path before publish.

gitlab.moselwal.io

MIT licence. Self-host, fork, contribute. No service pitch.