Skip to product information
1 of 7

CRMi Premium Theme Module for Dolibarr ERP/CRM

Regular price €299,00
Regular price Sale price €299,00
Sold out

1 Executive Summary

CRMi is a commercial theme module for the Dolibarr ERP/CRM platform, published by DoliResources. It replaces the whole application shell - left sidebar, top...

5 people are viewing this right now

View full product details

1 Executive Summary

CRMi is a commercial theme module for the Dolibarr ERP/CRM platform, published by DoliResources. It replaces the whole application shell - left sidebar, top bar, home dashboard and sign-in page - and ships seven complete, switchable demonstration configurations: CRM, Business Analytics, Human Resources, Production, Project Management, eCommerce and Restaurant. Switching from one demo to another is a single selection on the configuration page; it repaints the palette, the chrome, the KPI card family, the dashboard layout and the sign-in page in one request, with no re-installation and no data migration.

CRMi is technically a module, not a CSS skin. A stylesheet alone can only recolour the markup Dolibarr already emits; it cannot build a profile rail, a live search bar, a notification tray or a KPI dashboard. CRMi therefore registers its own menu manager, its own dynamic stylesheet and script, four hooks and a custom home page. It modifies no file of the Dolibarr core, creates no database table, and declares no permission of its own: it obeys the rights of the modules whose data it displays.

The distinguishing property of the product is that every figure on every dashboard is a real aggregate of the host database. Where a mock-up asked for a quantity Dolibarr does not record - web visitors, star ratings, restaurant covers, a remote/on-site flag - CRMi either binds the widget to a genuinely measured quantity and captions it for what it truly is, or replaces it with an explicit note. No figure is simulated, a disabled module produces a written notice rather than a silent zero, and a rate is never printed over an empty population.

This document describes the delivered functionality, the configuration surface, the integration model, and - in section 47 - the precise boundaries of what has and has not been validated at the time of writing. Version 1.0.0, 21 July 2026.

2 Theme Overview

CRMi is distributed as a standard Dolibarr external module. It installs under custom/crmi/, is enabled from the Interfaces family of the module list, and is configured from a single settings page reachable from the module list or from the top-bar user menu.

Property

Value

Commercial name

CRMi

Technical name / folder

theme_crmi / crmi

Descriptor class

modCrmi (numero 10000760)

Constant prefix

CRMI_

Version

1.0.0

Module family

interface

Editor

DoliResources - https://www.doliresources.com

Licence

GPL-3.0-or-later

Declared minimum Dolibarr

16.0

Declared minimum PHP

7.0

Validated on

Dolibarr 23.0.3, PHP 8.1, MariaDB

Database tables created

None - configuration lives in llx_const

Dolibarr core files modified

None

Permissions declared

None

Distribution archive

module_crmi-1.0.zip, root folder crmi/, about 248 KB

 

The code base is compact and auditable: 20 PHP files totalling roughly 10,170 lines, one dynamic stylesheet generator of about 2,400 lines, seven per-demo CSS partials totalling 2,473 lines, one dynamic script, and seven language files of 491 keys each.

The module injects its stylesheet and its script on every page through the native module_parts mechanism, forces its own menu manager through the four MAIN_MENU*_FORCED constants, registers hooks on the main, all, toprightmenu and searchform contexts, and redirects the Dolibarr home page to its own dashboard. Every one of those integration points is a documented, supported Dolibarr extension mechanism.

3 Design Objectives

Four objectives governed the design, and each of them is visible in the delivered code.

·       Replace the shell, not the application. Dolibarr's business pages, forms, permissions and workflows are untouched. CRMi restyles them and rebuilds only the navigation and the home page. A user who knows Dolibarr keeps every habit; an administrator keeps every escape hatch, including the ability to disable the custom dashboard and keep the native home page.

·       Make the look a configuration, not a fork. One preset array is the single source of truth for the stylesheet, the script, the dashboard, the sidebar and the settings page. The default of every setting is read from that same array, so a reset can never restore a palette that differs from the one the stylesheet actually ships, and no setting can silently become a no-op.

·       Tell the truth about the data. A dashboard whose numbers are invented is worse than no dashboard: it teaches the user to distrust the tool. CRMi therefore accepted a plainer picture than the reference mock-ups in several places, in exchange for figures a controller can reconcile with a Dolibarr list.

·       Ship nothing decorative that does not work. Every control in the top bar is wired to a real feature. Two controls that would have been dead on a plain installation - the Documents shortcut and the entity switcher - are not rendered at all unless the underlying feature exists on the install.

A fifth, quieter objective was operational: the theme had to be removable. Disabling the module deletes the forced-menu constants and its own asset-version marker, and Dolibarr returns to its previous theme. No business record is created, altered or deleted at any point in the module's lifecycle.

4 UI/UX Philosophy

CRMi is built on a design-token model. The active preset emits two sets of CSS custom properties - one for light mode, one for dark - covering surfaces, text levels, borders, the primary and accent colours and their translucent variants, the semantic success, danger and warning colours, the sidebar family, the top bar, three shadow levels, the corner radius, the border width, the rail width, the grid gutter, the font stack and the five chart colours. Every component reads only those tokens. That single indirection is what makes a demo switch, a palette change and the light/dark switch total and instantaneous rather than partial.

The interface language is deliberately calm. Cards are white (or a real dark surface in dark mode) with a one-pixel border and a soft shadow, both of which the administrator can turn off entirely for a borderless, shadow-only look. Colour is used to carry meaning - a status, a series, a direction of travel - and not to decorate. Icon chips carry the colour on dark surfaces, because a saturated flat tint at low alpha turns muddy on a navy canvas.

Density is a setting, not a fixed opinion. The page layout offers fluid, boxed, full width, compact, comfortable, two-column and floating variants; compact reduces both the grid gutter and the base font size, comfortable widens the gutter. The base font size, the corner radius and the gutter are individually adjustable, so the same theme can serve a data-dense back office and a presentation-grade management dashboard.

Motion is decorative and optional. Animations can be switched off globally, and the stylesheet also honours the operating system's prefers-reduced-motion setting independently of that switch, collapsing transitions and hover transforms.

5 CRMi CRM Demo

The CRM demo is the shipped default and the reference for the family: a white left rail carrying the CRMi mark and a profile card, purple active labels, and a very light grey canvas. Its accent is a clear blue (#4A9DF7) against the shared purple primary (#6E3FE7), and its KPI family is bignum - a large figure with a small tinted icon in the corner, one tile of the row rendered as a saturated purple solid among white ones.

The layout opens on a wide Prospect status panel drawn as horizontal multicolour bars, each bar a clickable link into the matching pre-filtered third-party list. To its right sits a two-by-two block of KPI tiles. Below, a full-width Invoice totals by status panel renders five vertical columns; beside it a Lead sources donut with a centred count, and under those a Customers by priority column chart and a five-day task horizon.

The visual signature of this demo is the horizontal bar histogram: long, rounded, individually tinted from the demo's six-colour chart ramp, each with its label and exact count on the same line. A short note under the panel states that bar geometry uses a square-root scale, so the reader knows the lengths are comparative rather than strictly proportional while the printed figures stay exact.

Its sign-in page uses the split layout: a full-height purple-to-blue gradient panel occupying the left 46% of the viewport, the credentials card floating to the right, collapsing to a coloured banner above a centred card below 900 pixels.

6 CRMi Business Analytics Demo

Business Analytics keeps the same purple primary but swaps the accent to a deep green (#1F9D74) and adopts the ring KPI family: each card pairs a square pastel icon tile with a donut ring whose centre carries the count and whose caption carries the share.

The page is a two-column grid. The main column starts with three project ring cards - total, ongoing and complete - then a wide Revenue Analytics combo panel that plots twelve monthly invoiced amounts as violet columns with an order-intake trend curve drawn over them, a legend above and a month axis below. Under the combo sits a row of three period stat boxes, each with its own variation arrow, and a short note explaining what the three periods are. The side column carries a tall Recent activity timeline - a vertical rail of dots, each row giving the elapsed time, the author, the action and a link to the object - and a sales donut split by customer type.

This is the most chart-forward of the seven layouts, and the one that best demonstrates the axis discipline of the theme: when the two series of the combo are of comparable magnitude the panel prints a note stating that both share one scale and what the top of the chart represents; when they are not, it prints instead that the second curve uses its own scale, and why.

Its sign-in page uses the card layout: the demo gradient fills the whole viewport and the credentials card floats on top of it with a deep drop shadow.

7 CRMi Human Resources Demo

The Human Resources demo returns to the blue accent and a slightly warmer canvas, and uses the delta KPI family: a large value, a caption, and a variation chip whose arrow and whose colour are computed separately.

Four delta cards open the page - total employees, leave requests, new employees and the leave approval rate. Below them a Working format donut splits the active population, a paired column chart shows project employment against a rolling quarterly average, and a stacked Total applications bar renders the recruitment funnel stage by stage. The page closes on a Recruitment progress table with avatar chips, candidate name, position, stage and date.

Every panel of this layout carries an explanatory sub-caption, because HR figures are the ones most often misread. The working-format donut states on screen that it compares internal employees with external users and that Dolibarr stores no remote/on-site flag; the leave volume panel states that it is a rolling twelve months and that no staff turnover rate can be derived because Dolibarr records no dated departure; the approval rate states that it is the share of decided requests and that pending requests are excluded from both sides of the ratio.

Its sign-in page uses the split layout, as the CRM demo does, with its own gradient.

8 CRMi Production Demo

Production is the darkest-accented of the vertical demos: primary purple against a royal blue (#4A6CF7), with the iconpill KPI family - a round pastel disc carrying the icon, the figure beside it, the caption underneath.

The layout opens with a full-height gradient status card carrying a ring gauge, flanked by three white cards with round pastel icons: total sales, profit and revenue. A wide Sales report panel then renders grouped columns for turnover, supplier costs and the net of the two over twelve rolling months, with a legend and a written alternative summary underneath. The page closes on the Production by unit panel: horizontal bars, one per warehouse, ordered by volume.

The gradient card is where this demo makes its honesty rule visible. When the manufacturing module is enabled, the gauge shows manufacturing completion over closed orders. When it is not, the card does not disappear and does not show zero: it shows the invoice collection rate instead, and its caption states exactly that, quoting the amount cashed against the amount invoiced. The reader always knows which quantity the ring is measuring.

Its sign-in page uses the gradient layout: the demo band fills the top 46% of the viewport, is cut by a wave mask, and the credentials card sits astride the cut.

9 CRMi Project Management Demo

Project Management is the amber demo: the accent is a warm gold (#F5B335) and the KPI family is gauge - an arc drawn behind the figure, filled to the measured share.

A large semicircular gauge dominates the top of the page, reading overall progress. Next to it, three phase badges - done, open and late - are drawn as coloured check, ring and clock chips, and a flag card announces the next project start date. The second band carries revenue on projects and a project budget column chart; the page closes on an overdue task table listing reference, project, due date, days late and progress, and a total of logged hours.

The three phase badges are deliberately disjoint - a task counted as late is not also counted as open - so the remainder computed by the layout can never go negative and the three numbers always add up to the task total. The gauge itself is a workload-weighted mean of task completion, not a plain average, so a one-hour task cannot outweigh a three-week one, and when no task carries a planned workload the panel says so instead of drawing an empty arc.

Its sign-in page uses the centered layout: a thin gradient rule across the top of the viewport, echoing the application top bar, above a centred card on a flat canvas.

10 CRMi eCommerce Demo

The eCommerce demo pairs the purple primary with a turquoise accent (#2DD4BF) and uses the iconpct KPI family: a header row carrying the icon and the variation percentage, the figure below.

Four KPI cards open the page - orders, credit notes, new customers, and stock alerts or overdue invoices depending on which modules are enabled. A Monthly sales panel then plots a dual-series line, and an Income/Expense panel offers a pill toggle over monthly columns. The lower half is built around the signature element of this layout: a dark navy Profit value panel carrying a channel donut, set against the light cards around it. Beside and under it sit a Popular products table and an order-outcome breakdown with a score caption.

The income/expense toggle is instructive. When the supplier invoice module is disabled the expense pill is still rendered, but visibly disabled, non-interactive and carrying a tooltip that names the missing module, and a note under the panel repeats it in words. The alternative - hiding the pill - would have left the reader believing that costs were measured and were zero.

Its sign-in page uses the card layout, over a three-stop gradient running from the demo's deep navy ink through purple to turquoise.

11 CRMi Restaurant Demo

The Restaurant demo is the most graphic of the seven: an amber accent (#F5A623) and the foodtile KPI family - three large centred pictogram tiles for new, delivered and cancelled orders, each with the figure under the pictogram and a source caption under that.

Below the tiles, a stacked column chart renders daily orders over twelve months, a smoothed area chart shows orders delivered per month, and a Daily flow panel draws paired columns over the last seven days. The page closes with a sales chart, a new-customers panel and a total-earnings panel, each with its own legend and caption.

This demo states its own premise on screen. A visible note explains that Dolibarr ships no restaurant module, that the dashboard is therefore presenting native commerce objects - orders, invoices, customers - under restaurant labelling, that connecting a point-of-sale module would replace them with real service data such as covers, tables and tickets, and that no figure on the page is simulated. Where the mock-up called for a customer-review carousel, the panel is replaced by a written explanation that Dolibarr stores no ratings and that this dashboard will not invent any.

Its sign-in page uses the gradient layout with a purple-to-amber band.

12 Dashboard Architecture

The dashboard is one page, custom/crmi/index.php, and it has a strict internal contract: one data layer, seven presentations. The page bootstraps Dolibarr, resolves the active preset, computes the shared datasets, then includes the per-demo dataset file and finally the layout named by the preset. A layout file lives in core/dashboards/<key>.php and is a pure presentation file - it must never run a query. That separation is what guarantees the property a buyer should test first: switching demo changes the arrangement and never the figures.

A layout is reachable only through index.php, which defines a guard constant; each layout and the data layer refuse to run otherwise. An unknown or unreadable layout key falls back to the CRM layout and writes a warning to the Dolibarr log rather than rendering an empty page.

The reporting period is user-selectable between week, month and year, and the previous comparable period is computed alongside it, so every variation on the page is a like-for-like comparison. Turnover has two administrator-level definitions: the amount basis (including or excluding tax) and whether invoices in the abandoned status are counted. Both feed the KPI, the charts and the links, so the tile, the chart and the destination list always agree.

Several honesty rules are enforced at this level rather than left to each layout:

·       A disabled module produces no row at all in the dataset, so the layout renders an explicit "the module is not enabled: no figure can be shown" note rather than a zero.

·       A rate is never printed over an empty population. The share helper returns a known flag alongside the percentage, and the layouts print n/a when it is false - because a 0% win rate on an install where every proposal is still in draft reads as "we lose every deal" when the truth is "nothing has been decided yet".

·       A variation separates two different questions: did the figure rise, which drives the arrow, and is that desirable, which drives the colour. A falling amount of unpaid invoices is therefore a down arrow in green. The same helper reports the variation as unknown when the previous value was zero, so no "+100%" is ever invented from nothing.

·       Monthly series always use twelve rolling buckets ending on the current month, and the year-on-year comparison is cut to the elapsed window, so a future month is never plotted as zero and no curve dives to the floor for the rest of the calendar year.

Under the custom panels, the page also renders Dolibarr's own widget zone (the native boxes) with its add, hide and drag-to-reorder controls, persisted per user by the core. On a user's first visit the zone is seeded with a sensible default set so that the add-widget selector appears. The whole zone can be hidden by a single setting, and the custom dashboard itself can be disabled, in which case Dolibarr's original home page is kept and only the chrome and the styling remain.

13 KPI Cards

A KPI card family is a facet of the preset, and the administrator can force one family on any demo without touching anything else. Seven families ship.

Key

Card style

Default demo

bignum

Big figure with a corner icon

CRM

ring

Icon tile paired with a donut ring

Business Analytics

delta

Figure with a variation arrow chip

Human Resources

iconpill

Round pastel icon disc

Production

gauge

Arc gauge behind the figure

Project Management

iconpct

Icon and percentage header, figure below

eCommerce

foodtile

Large centred pictogram tile

Restaurant

 

Whatever the family, a card carries the same four elements: a caption naming the measure, the value, a sub-caption naming the source or the period, and - where a comparison exists - a variation. Cards are clickable: each one links to the native Dolibarr list filtered to the same scope as the tile, including the same date range and the same status set, so that the total at the bottom of the list matches the number on the card. A card whose module is disabled keeps its place in the grid and shows the not-enabled note in place of the figure, which preserves the visual rhythm of the row without pretending to measure anything.

The KPI row of the home dashboard also carries a sparkline under each figure. The bars use a square-root scale: with real ERP data one month is routinely a hundred times another, and a linear scale flattens every other bar to a hairline. The printed figures remain linear and exact.

14 Sidebar Features

The sidebar is rendered by CRMi's own menu manager, which fills its tree from the native Dolibarr menu system with output suppressed. That matters: every module's menu entries, every menu hook and every permission filter keep working, and a newly installed module appears in the CRMi rail without any adaptation. If the custom rendering is disabled or fails, the manager falls back to the native left menu, so pages never break.

From top to bottom the rail carries:

·       A brand row. When a company logo is configured it is used; otherwise CRMi draws its own mark - an original inline SVG built from a rounded tile, an open arc and a dot - whose colours are theme custom properties, so it re-tints with the palette and follows dark mode without a second asset file.

·       A profile card with the avatar or initials, the full name and the role. It can be hidden to give the navigation more vertical room.

·       A module search box that filters the visible tree as the user types.

·       The live menu tree, filtered by rights and entity, with the current section expanded and the current sub-entry highlighted.

·       Count badges on the top-level entries: unpaid invoices, open proposals, prospects, today's events and ongoing projects. A badge is emitted only when its module is enabled and its count is non-zero, so no badge is ever a dead number. The whole set can be switched off.

·       A favourites section, shown only when the Dolibarr bookmark module is enabled, with an add-this-page control.

·       A recently-opened list, populated from the object cards the user actually visits, with a configurable length.

·       A call-to-action button at the foot of the rail, opening the theme settings for an administrator or the user's own account otherwise.

The rail collapses to an icon-only strip; the collapsed state is persisted in the browser and re-applied before the first paint, so a reload lands directly in the right state with no folding animation. Below 760 pixels the rail is not folded but converted into an off-canvas drawer with a backdrop. The rail width is configurable, and the sidebar surface can be forced to light, dark or coloured independently of the demo - with the text and active-pill tokens re-derived accordingly, so a forced dark rail never leaves a label unreadable.

15 Topbar Features

The top bar is rendered server-side from the native toprightmenu hook rather than from the cached script, for two reasons: the script is served with a one-hour cache and any counter baked into it would be up to an hour stale, and only PHP can emit an escaped, CSRF-tokened form. The CSS turns the two native wrappers into display:contents so the bar becomes a direct flex child of the header and can span the full width.

The left cluster carries the sidebar-collapse burger and the global search form. The right cluster carries, in order:

·       Notifications: a dropdown counting overdue customer invoices, expired proposals and the current user's overdue agenda actions. Each line is a link into the matching native list, already filtered. Each source is included only if its module is enabled and the user has the read right on it, and an empty tray shows a written all-clear state rather than a zero.

·       An applications grid listing the modules that are both enabled on this installation and readable by this user, each entry pointing at a real Dolibarr landing page.

·       A Documents shortcut - rendered only when the ECM module is enabled and readable.

·       Messages: the current user's open agenda actions, with a live count badge.

·       A language selector listing every language available in the installation (51 on the test install). The choice is submitted by POST under Dolibarr's own CSRF check and persisted through the native user-parameter mechanism, which is exactly what the core reads back on the next request.

·       A fullscreen button, using the browser Fullscreen API and rendered hidden until the script confirms the API exists.

·       A light/dark toggle, persisted per browser.

·       A user block with avatar, name and role, opening a menu with the user profile, the native display settings, the theme settings for administrators, the entity switcher when more than one entity exists, and the native logout.

Two controls were deliberately omitted rather than faked: the Documents shortcut on an install without ECM, and the entity switcher on a single-entity install. Nothing in the bar is a decorative button that does nothing. The whole bar can be hidden by one setting for administrators who prefer the native header.

16 Global Search

The search field in the top bar submits to the theme's own cross-object search page, custom/crmi/search.php, with a CSRF token. The page queries eight object families in parallel and groups the results by family, each group carrying its icon, its colour, up to six rows and a see-all link into the corresponding native list pre-filtered with the same term.

The families searched are third parties (name, alias, customer code, town, e-mail, phone), contacts (last name, first name, e-mail), products and services (reference, label), invoices, proposals and orders (reference), projects (reference, title) and users. Every group is gated on the corresponding Dolibarr read permission, so a user only ever sees what the core would let them open, and each row links to the object card.

An empty query renders a guidance state naming what can be searched; a query with no match renders a distinct no-result state with the term quoted back. The search page is responsive, collapsing to a single column below 600 pixels.

17 CRM Features

The CRM dataset is built on the third-party module and, for its widgets, on proposals, orders, invoices and projects.

Prospect status reads the commercial status stored on the third party, restricted to prospects, and groups it by that status - never contacted, to contact, contacted, in progress, won, lost. The labels are the ones Dolibarr itself uses, and each bar links to the third-party list filtered on the same status, so the count is verifiable in one click. Customers by priority is derived from the same column the native prospect list uses, so the two always agree.

Lead sources are read from the demand-origin dictionary. The origin in Dolibarr is recorded on the documents, not on the third party: the query therefore reads the proposal table when the proposal module is enabled, and falls back to orders, then invoices. Where none of the three is enabled, the donut is not drawn. Legend labels are HTML-decoded before being handed to the chart, because an accented dictionary label would otherwise be printed as an entity inside the graphic.

Invoice totals by status split validated invoices into paid, unpaid and not yet due, overdue, draft, and credit notes, on the configured turnover basis. The five columns come from five separate aggregates over the same table, so they are additive and reconcilable with the invoice list. Tasks due in the next five days reads the project task table, one bucket per day.

Module behaviour: with the third-party module disabled, the prospect, priority and lead-source panels are replaced by a not-enabled note. With the invoice module disabled, the invoice-status panel and the unpaid KPI show the same note while the rest of the page continues to render. With the project module disabled, the ongoing-projects tile and the five-day task horizon do the same.

18 Business Analytics Features

The analytics dataset is centred on the project module and on the invoicing chain.

The three ring cards count projects by native status: total, ongoing and complete, each ring showing the share of the total and each card linking to the project list. Revenue Analytics plots the invoiced amount per month over twelve rolling buckets, on the configured turnover basis and status filter, with an order-intake series computed over exactly the same buckets so the columns and the curve are directly comparable. When the order module is disabled the second series is absent rather than flat at zero, and the panel says so.

The three period stat boxes exist because Dolibarr keeps no daily turnover aggregate. Rather than inventing a daily series, the panel shows the last closed month, the current period and the year to date, each with its own variation against its own comparable period, and states that reasoning on screen.

Recent activity is a merge of the most recently modified invoices, orders, proposals and third parties, sorted by timestamp, each row carrying the author, the action, a relative time and a native link with the standard Dolibarr hover tooltip. The sales donut splits invoiced amounts by the customer type dictionary - a real dimension of the third-party record, not an inferred segmentation - and drops rows whose total is not positive.

Module behaviour: without the project module the three ring cards are replaced by a not-enabled note and the rest of the page still renders. Without the invoice module the revenue series and the sales donut are empty and captioned as such. Without the third-party module the sales donut is not drawn at all.

19 Human Resources Features

The HR dataset draws on the user table, which is always present, and on the leave, recruitment and project modules where they are enabled.

Total employees counts active user accounts in the entity; new employees counts accounts created in the period against the previous one, and the caption states that it is measuring account creation. Headcount has no dated history in Dolibarr, so the total carries a note saying so rather than a fabricated trend.

Leave requests count holiday records opened in the period, with the previous period as the comparison and with falling volume treated as the desirable direction. The leave approval rate is the ratio of approved to decided requests: pending requests are excluded from both sides, because including them in the denominator would report a permanently depressed rate that improves only when people stop applying. When nothing has been decided yet the card prints n/a and explains why.

Working format is the clearest illustration of the theme's substitution rule. The mock-up called for a remote versus on-site split; Dolibarr stores no such flag. The panel therefore splits the active population along a dimension that does exist - internal employees versus external users attached to a third party - and its sub-caption states exactly that.

Recruitment reads the job-position and candidature tables, building a funnel over the native candidature statuses - applications, shortlisted, on hold, hired, rejected - and a table of the six most recent candidates with their position and stage. Project employment counts internal contacts assigned to project tasks and derives the unassigned remainder from the active headcount.

Module behaviour: the leave panels, the approval rate and the monthly leave volume are replaced by a not-enabled note without the holiday module; the funnel and the candidate table by the same note without the recruitment module; the staffing panel likewise without the project module. The headcount cards and the working-format donut always render, because the user table always exists.

20 Production Features

The production dataset spans manufacturing orders, stock and the invoicing chain.

When the MRP module is enabled, CRMi counts manufacturing orders in total, produced, running and late, plots their creation over twelve rolling months, and computes a completion rate over decided orders only - produced against produced plus cancelled - so that orders still in progress do not mechanically depress the rate. When MRP is not enabled the status card does not vanish and does not show zero: it falls back to the invoice collection rate, and its caption quotes the amount cashed against the amount invoiced so the reader knows which quantity is on screen.

The sales report plots three series over the same twelve buckets: turnover from validated customer invoices, supplier costs from validated supplier invoices, and the net of the two. Where the supplier module is disabled, the cost and profit series are not computed at all - a zero-cost line would assert that the business has no costs - and the panel prints a note saying costs are unknown, so no profit or expense series is drawn.

Production by unit crosses the warehouse table with stock movements, summing absolute movement volume per warehouse and keeping the six largest. It measures recorded stock movement, which is what Dolibarr can prove, and the panel is titled and captioned accordingly. Warehouse labels are HTML-decoded before being drawn.

Module behaviour: without the stock module the by-unit panel shows a not-enabled note; without the invoice module the turnover card and the sales report do the same; without the supplier module the cost and profit series are omitted with a written explanation while the turnover series continues to be drawn.

21 Project Management Features

This dataset reads the project and task tables, the task time records and the invoices attached to projects.

Overall progress is a workload-weighted mean of task completion. Task progress in Dolibarr is already a percentage, so the weighted mean is built against a denominator carrying the same scale on both sides; the earlier, naive formulation reported figures above a hundred per cent next to a bar pinned at full, which is the class of defect this product is designed to avoid. Where no task carries a planned workload the gauge is replaced by a note.

The three phase counters are computed to be disjoint. Done is tasks at a hundred per cent; late is tasks below a hundred per cent with a past due date; open is the remainder. The three therefore sum to the task total by construction. The overdue table lists the six oldest overdue tasks with their project, due date, days late and progress.

Budget compares the sum of project budget amounts with the amount invoiced against projects, and carries a known flag: where no project declares a budget, the panel says so instead of showing an infinite or zero consumption. Logged hours are summed from the task time table. The next-start card reads the earliest future start date among ongoing projects, and prints n/a when there is none.

Module behaviour: this layout is entirely dependent on the project module. When it is disabled the page renders a single, explicit not-enabled note rather than a grid of empty panels. The revenue-on-projects figure additionally requires the invoice module.

22 eCommerce Features

The eCommerce dataset is built on orders, invoices, products and stock.

Orders are counted in total, delivered and cancelled, with a twelve-month series and an average basket computed over validated orders only, carrying a known flag so that an install with no validated order shows n/a rather than zero. Credit notes stand in for returns: Dolibarr has no return object, but a credit note is a real, auditable document, and the card is labelled for what it counts.

Income and expense are two twelve-month series - validated customer invoices and validated supplier invoices - offered under a pill toggle. When the supplier module is off, the expense pill is rendered disabled with a tooltip naming the missing module and a note under the panel; the income series continues to be drawn.

Popular products are computed from invoice lines rather than order lines. On a real installation many order lines carry no product reference at all, so ordering by order lines silently returns an empty table; invoice lines are the reliable source, and the table shows reference, label, quantity and amount for the six best sellers. Stock alerts count products at or below their configured alert threshold, and the fourth KPI card falls back to overdue invoices when the stock module is absent.

Module behaviour: without the order module the order KPIs, the monthly series and the outcome breakdown carry the not-enabled note; without the invoice module the money panels and the product table do the same; without the product module the best-seller table alone is replaced; without stock, the alert card falls back rather than disappearing.

23 Restaurant Features

Dolibarr ships no restaurant module, and CRMi does not pretend otherwise. This dashboard maps restaurant vocabulary onto the native commerce objects and states the mapping on screen: new orders are customer orders still in draft, delivered orders are orders marked delivered, cancelled orders are cancelled orders, and each tile carries a source caption saying so. A note explains that connecting a point-of-sale module would replace these with real service data - covers, tables, tickets - and that no figure on the page is simulated.

The daily-orders column chart splits each month into two disjoint groups whose sum is the month total: orders not cancelled, then cancelled orders. The stacking is therefore arithmetically sound rather than decorative, and a note states it, together with the fact that column heights use a square-root scale while the quoted figures are the real counts. The delivered-orders area chart carries a specific empty state explaining that on a real install the series is legitimately flat until orders are closed.

The Daily flow panel replaces a dine-in versus online comparison, which Dolibarr cannot record, with two dimensions it does record: orders taken and invoices issued, over the last seven days. The earnings panel plots a single twelve-month series and explains that the second, prior-year series of the mock-up is not part of this dataset and is therefore not drawn rather than approximated. Where the mock-up carried a review carousel, the panel carries a written statement that Dolibarr stores no ratings and that none will be invented.

Module behaviour: the whole layout depends on the order module and says so in one place when it is missing, explaining that a zero would read as "no business" rather than as "not measured". The invoice-derived panels and the new-customer panel degrade individually with their own notes.

24 Widgets

CRMi renders three kinds of widget, and it is worth distinguishing them.

The first kind is the demo panel: the cards, charts and tables described in sections 5 to 23. They are laid out by the active demo, bound to real aggregates, and captioned with the source of the figure. Their common shell is shared - title, optional legend, optional sub-caption, body, optional footer note - so the seven layouts read as one product.

The second kind is the empty or degraded state, and CRMi treats it as a first-class widget rather than an afterthought. There are three distinct states and they say different things: the module is not enabled, so nothing can be measured; the module is enabled but no matching record exists yet, so the panel will fill in by itself; and the population is empty, so a rate cannot be stated. A user who sees one of them knows whether to enable a module, to enter data, or to wait.

The third kind is the native Dolibarr box. The home page keeps the core widget zone with its selector, its close controls and its drag-to-reorder behaviour, all persisted per user by the core itself. This means every widget shipped by any other installed module remains available on the CRMi home page, which is an important integration property: the theme adds panels without removing the ecosystem's.

Where a mock-up widget had no Dolibarr source at all - web visitors, customer complaints, star reviews, a remote/on-site flag, restaurant covers and tables - the widget is either rebound to a genuinely measured quantity and re-captioned, or replaced by an explicit note naming what is missing and what would fill it. Section 47 lists every such case.

25 Charts and Data Visualization

All charts on the CRMi dashboards are inline SVG generated server-side by the theme, with no charting library, no external asset and no client-side data fetch. Colours come from the preset's five-colour chart ramp, so a palette change repaints every series consistently.

The chart vocabulary is deliberately small: vertical columns and grouped columns, stacked columns, horizontal bars, smoothed line and area curves with a shared or explicitly separate scale, donut and ring arcs, semicircular gauges, and bar sparklines. A dual-series curve draws both series against one scale and a dotted vertical guide grid, with point markers on both curves; the interactive revenue chart adds a cursor guide with a value tooltip.

Four rules apply to every chart in the product:

·       Twelve rolling months, ending on the current one. A monthly chart needs twelve buckets; plotting only the current month leaves eleven empty columns that read as a collapse rather than as an absence of data. Year-on-year comparisons are cut to the elapsed window on both sides, which is also the only honest comparison.

·       A square-root geometry for bar and column lengths, so a dominant value cannot flatten the others to hairlines. Printed figures stay linear and exact; large amounts are abbreviated in the label with the exact value available in the tooltip, and the panels concerned carry a note stating the convention.

·       One scale, or an explicit statement that there are two. Where two series are comparable the panel states that both share a scale and what the top of the chart represents; where they are not, it states that the second uses its own scale and why.

·       No decorative series. A series whose module is disabled is not drawn as a zero line; it is omitted and named in a note under the chart.

Every chart also carries a text alternative: an aria-label summarising the series and their values, or a visually hidden summary block, so the information is available without the graphic. Legends are HTML-decoded before rendering, which prevents accented dictionary labels from appearing as entities inside a graphic.

26 Tables and Lists

CRMi restyles Dolibarr's own list machinery rather than replacing it. The responsive table container becomes the card: it carries the border, the radius and the shadow, while the table inside it is stripped of its own frame so the two do not form a double outline. Filter bars, header rows, header underlines, row separators, hover states and the last-row border are all retinted to theme tokens - several of them because the core hardcodes colours that are near-white or, in dark mode, the primary colour, and both read badly on a data grid.

Pagination, action buttons, tab bars and the info and warning notice boxes receive the same treatment, as do the agenda month calendar cells, whose core styling hardcodes light backgrounds and grey borders that are unusable on a dark canvas.

The tables drawn by the dashboards themselves - recruitment progress, overdue tasks, popular products, latest invoices, top accounts - follow the same visual grammar: a header row in muted small caps, rows separated by a token border, status rendered as a coloured chip, and the reference column rendered through Dolibarr's own object link helper so the reader gets the standard hover card and the standard permissions.

27 Forms

Form controls are restyled globally: inputs, selects, text areas, checkboxes and file fields take the theme's radius, border token and font, and receive a visible focus state in the primary colour rather than the browser default outline. Buttons follow the same token set, with the primary, cancel and delete variants mapped onto the theme's primary, neutral and danger colours.

CRMi adds only two forms of its own. The first is the global search field in the top bar, a GET form carrying a CSRF token. The second is the configuration page, a POST form with a token, whose fields are generated from the same settings definition that validates them on save - which is why an out-of-range value can never be stored. The configuration page additionally offers a JSON export and a multipart import form, kept outside the main form because nesting forms is invalid HTML and browsers silently drop the inner one.

All other forms in the application remain Dolibarr's own, with their own validation, their own permissions and their own hooks.

28 Login Pages

The sign-in page is styled entirely in CSS, over the markup Dolibarr owns; CRMi adds no element to the login DOM and changes no authentication behaviour. Because a visitor at the sign-in page has no session preference yet, the demo is resolved server-side from the stored configuration - the one place in the theme where the administrator's default is authoritative, which is the correct behaviour for a shared page.

Five login layouts are implemented:

Layout

Description

Used by

split

Full-height gradient panel on the left, form on the right

CRM, Human Resources

card

Gradient fills the page, the card floats on it

Business Analytics, eCommerce

gradient

Hero band cut by a wave, card astride the cut

Production, Restaurant

centered

Thin gradient rule on top, centred card

Project Management

minimal

Flat canvas, borderless card with a coloured top rule

No shipped preset

 

All five share a brand line above the form, drawn from the configured application title, and all five clear Dolibarr's own two-tone diagonal background. The split and gradient layouts carry their own narrow-screen rules, folding the coloured panel into a banner above the form. In dark mode the company logo is inverted so that a dark logo remains visible on a dark card.

The seven sign-in pages had not been visually validated at the time of writing; see section 47.

29 Responsive Design

The layout is fluid by default and reflows at five breakpoints. Above 1400 pixels the dashboard grids use their full multi-column arrangement; at 1400 and 1200 pixels the wider grids progressively reduce their column count; at 1100 pixels two-column panels collapse to one and the horizontal navigation family switches from hover menus to click menus; at 960 pixels the native widget zone stacks its two columns; at 760 pixels the sidebar becomes an off-canvas drawer with a backdrop, the top bar compresses, and the dashboard becomes a single column. The search page collapses to one column at 600 pixels.

The folded rail is a desktop-only state by design. The pre-paint script explicitly does not apply the collapsed class below 760 pixels, because on a phone the correct behaviour is a drawer, not a 72-pixel icon strip taking a fifth of the width.

The horizontal navigation family has a fixed height budget of one row and therefore caps the number of visible top-level entries, moving the remainder into a trailing More panel; the active module is always promoted into the visible set so the current section is never hidden. The cap is configurable.

What was actually measured: the seven dashboards were checked for horizontal overflow at 1600 pixels, and the top bar was inspected visually at 1600 by 990 and at 390 pixels, in light and dark, expanded and collapsed. Full tablet and smartphone passes over all seven dashboards had not been carried out at the time of writing; see section 47.

30 Dark Mode

Dark mode is a genuine second surface set, not a filter or an inversion. The stylesheet emits two complete token blocks from the active preset - one under :root for light, one under a data attribute on the document element for dark - covering the canvas, three card levels, three text levels, two border levels, the sidebar family, the top bar and the translucent variants of every semantic colour. Because every component reads only tokens, the switch is total and instantaneous.

The dark surfaces are real dark surfaces rather than tinted light ones. A saturated orange or red flat, even at low alpha, turns brown on a navy canvas; in dark mode the colour therefore lives in the icon chip and in the figure, and the card stays neutral. Several core colours that are hardcoded in Dolibarr - the near-white row separator, the cyan info box, the calendar cell backgrounds, the list header underline - are explicitly retinted, because they are the elements that betray a half-finished dark theme.

The mode is selected by the top-bar toggle and persisted per browser. A demo may declare that it starts dark, and an administrator can set a dark default for the entity; in both cases a choice the user has already made wins. The state is applied to the document element before the first paint by an inline script emitted server-side, so a reload never flashes light before turning dark. Selecting another demo on the configuration page also clears the browser's stored light/dark choice, so the new demo's own default is not masked by a stale preference.

Dark mode had not been visually validated across all seven demos at the time of writing; see section 47.

31 Theme Configuration

All configuration lives on one page, admin/setup.php, in five groups. Administrators may view and save; on a demonstration platform non-administrators may view the page with the controls visibly disabled, and every write is additionally blocked server-side. The page opens with a gallery of the seven demos, each card painted in that demo's own five colours and carrying a preview link that repaints the whole theme for the current session without touching the stored configuration.

Thirty-seven settings are exposed:

Group

Setting

Type

Default

Effect

Demo

CRMI_DEMO

select

crm

Active demo among the seven

Demo

CRMI_PALETTE

select

preset

Palette override, 9 named plus custom

Demo

CRMI_KPI_STYLE

select

preset

Force one of the seven KPI families

Demo

CRMI_DARK_DEFAULT

bool

0

Start in dark mode for users who never chose

Demo

CRMI_NAV

select

preset

Force vertical or horizontal navigation

Demo

CRMI_HERO

select

preset

Hero band: demo default, wave or none

Demo

CRMI_DEMO_PERUSER

bool

0

Let each user keep their own demo

Appearance

CRMI_COLOR_PRIMARY

colour

demo primary

Primary colour when palette is custom

Appearance

CRMI_COLOR_ACCENT

colour

demo accent

Accent colour when palette is custom

Appearance

CRMI_COLOR_SUCCESS

colour

demo success

Semantic success colour

Appearance

CRMI_COLOR_DANGER

colour

demo danger

Semantic danger colour

Appearance

CRMI_COLOR_WARNING

colour

demo warning

Semantic warning colour

Appearance

CRMI_FONT

select

quicksand

Font family among seven stacks

Appearance

CRMI_RADIUS

int

14

Corner radius in pixels

Appearance

CRMI_FONTSIZE

int

14

Base font size in pixels

Appearance

CRMI_WEBFONT

bool

1

Load the web font; off means no external call

Layout

CRMI_LAYOUT

select

fluid

Page layout among seven variants

Layout

CRMI_SIDEBAR_MODE

select

preset

Sidebar surface and geometry

Layout

CRMI_HEADER

select

preset

Header variant among eight

Layout

CRMI_SHADOW

select

soft

Shadow scale: none, soft, medium, strong

Layout

CRMI_BORDERS

bool

1

Card borders on or off

Layout

CRMI_GAP

int

24

Grid gutter in pixels

Layout

CRMI_ANIMATIONS

bool

1

Hover, fade, slide and collapse transitions

Layout

CRMI_RTL

bool

0

Right-to-left mirroring

Sidebar

CRMI_MENU_WIDTH

int

250

Rail width in pixels

Sidebar

CRMI_HIDE_PROFILE

bool

0

Hide the profile card

Sidebar

CRMI_HIDE_MENU_BADGES

bool

0

Hide the menu counters

Sidebar

CRMI_HIDE_CTA

bool

0

Hide the bottom call-to-action button

Sidebar

CRMI_HIDE_FAVORITES

bool

0

Hide the favourites section

Sidebar

CRMI_HIDE_RECENTS

bool

0

Hide the recently-opened section

Sidebar

CRMI_RECENTS_MAX

int

5

Number of recently-opened items

Sidebar

CRMI_HIDE_TOPACTIONS

bool

0

Hide the CRMi top-bar cluster

Dashboard

CRMI_DISABLE_DASHBOARD

bool

0

Keep Dolibarr's original home page

Dashboard

CRMI_HIDE_CORE_BOXES

bool

0

Hide the native widget zone

Dashboard

CRMI_TARGET_YEAR

int

0

Annual turnover target; 0 derives it

Dashboard

CRMI_CA_BASE

select

ttc

Turnover basis: including or excluding tax

Dashboard

CRMI_CA_INCLUDE_ABANDONED

bool

0

Count abandoned invoices in turnover

 

Saving or resetting bumps Dolibarr's interface revision counter, which is embedded in the stylesheet and script URLs, so a palette or demo change is visible on the next page load rather than after the browser cache expires. A reset deletes the theme's constants and returns every setting to the preset's own value.

The whole configuration can be exported as a JSON file and imported on another instance. The import validates every incoming value against the same definition used to render the form: an unknown key is ignored, an out-of-range selection or a malformed colour is skipped and counted, and the file size is capped. A crafted file therefore cannot write an arbitrary constant, inject markup or enable anything outside this theme.

Palette

Primary

Accent

preset (default)

the demo's own

the demo's own

CRMi Purple

#6E3FE7

#4A9DF7

Indigo

#4F46E5

#818CF8

Blue

#2F6FED

#60A5FA

Cyan

#0EA5E9

#22D3EE

Green

#1F9D74

#5BC98F

Orange

#F5A623

#FBBF5C

Coral

#F0526B

#FB8A72

Pink

#E8447E

#F97BA8

Navy

#231D54

#6E3FE7

Custom

administrator's choice

administrator's choice

 

Choosing a palette other than the demo default recolours every derived surface as well as the primary and accent: the active sidebar pill or its text, whichever preserves contrast, the top bar surface, the first KPI tint, the first tile, the first chart colour and the sign-in gradient. Leaving a derived token pointing at the old colour would make the setting look partly inoperative, which is why they are recomputed together.

Font key

Family

Web font required

quicksand

Quicksand (default)

Yes

nunito

Nunito Sans

Yes

inter

Inter

Yes

poppins

Poppins

Yes

lato

Lato

Yes

roboto

Roboto

Yes

system

System UI stack

No

 

32 User Preferences

CRMi distinguishes three scopes of preference, and it is worth understanding which is which before rolling the theme out.

Entity scope. Everything on the configuration page is stored per entity, so a multi-entity installation can give each entity its own look.

User scope. Per-user demos are an opt-in setting: once enabled, each user may keep their own demo while the entity keeps a default. The choice is stored as a plain constant, so it survives a reconnection exactly like the global one. The interface language is also a per-user preference, stored through Dolibarr's own user-parameter mechanism, and the native widget zone of the home page is ordered and filtered per user by the core.

Browser scope. The light/dark choice and the collapsed state of the sidebar are stored in the browser's local storage, because they are ergonomic rather than organisational: a user working on a laptop in a dark room and on a large screen in daylight legitimately wants different answers. Both are re-applied before the first paint. A user's stored light/dark choice always wins over the demo default and over the administrator's dark default.

A fourth, transient scope exists for evaluation: appending a demo parameter to any URL previews that demo for the current session only, and a reset value returns to the configured one. The preview is remembered in the session rather than read from the query string on each request, because Dolibarr emits the module stylesheet with a fixed URL: a query-string-only preview would repaint the markup while the stylesheet kept serving the stored demo.

33 Accessibility

Accessibility was treated as a rendering requirement rather than an afterthought, and the following are implemented in the shipped code.

·       Semantics: the navigation is a nav element with a label, dropdown triggers carry aria-haspopup, aria-expanded and aria-controls, panels carry a menu role, and menu entries carry a menuitem role.

·       Keyboard: dropdown panels close on Escape and return focus to their trigger; the horizontal navigation opens submenus on Enter and closes them on Escape; focus-visible outlines in the primary colour are declared for the top bar, the navigation links and the submenu entries rather than being suppressed.

·       Names: every icon-only control carries an accessible name and a matching tooltip. Icons are marked aria-hidden so a screen reader does not announce a glyph name, and truncated labels keep their full text as both title and accessible name.

·       Charts: each chart carries either an aria-label summarising its series and values or a visually hidden text summary, so no information exists only as a shape. Decorative bands and waves are drawn with CSS pseudo-elements, which are never announced.

·       Motion: the stylesheet honours prefers-reduced-motion by collapsing animation and transition durations and neutralising hover transforms, independently of the administrator's animation setting.

·       Colour: variation indicators carry an arrow as well as a colour, so direction is not conveyed by hue alone.

Two caveats belong here rather than in a marketing claim: no formal WCAG audit has been carried out on the product, and no assistive-technology test pass has been run. The right-to-left setting exists and mirrors the layout, but no shipped preset selects it and it has not been validated with an RTL language.

34 Performance Optimization

The theme adds one stylesheet request and one script request per page, both served by PHP and both small. Several deliberate choices keep the cost low.

·       Only the active demo's CSS partial is emitted. The seven per-demo partials total 2,473 lines; a browser downloads one of them, never the other six.

·       No charting library, no icon font of our own, no image assets. Charts are inline SVG generated server-side, and the brand mark is inline SVG built from theme tokens. The only external request the theme can make is the Google Fonts import, and a single setting turns it off in favour of the system font stack.

·       The script is cached for an hour and contains no translated string and no counter: everything volatile is rendered server-side by the top-bar hook, so the cache can be long without going stale.

·       The stylesheet is explicitly not stored by the browser. This is a considered trade-off, documented in the source: Dolibarr emits an identical stylesheet URL for every demo, so a long cache made the browser reuse the first demo's sheet for every later one - the server sent the right file, the browser never asked for it, and only the picture showed the error. Since the sheet is per-user and per-demo dynamic, it is not stored; the cost is one small request per page.

·       Configuration changes bump Dolibarr's interface revision, which is part of the asset URLs, so end users pick up a new look on a normal reload rather than needing a forced refresh.

·       Dashboard queries are simple aggregates with explicit entity filters and small limits, and the per-request menu badge computation is memoised.

No formal performance benchmark was run, and none is claimed. The figures quoted above are properties of the code, not measurements of page-load time.

35 Security Considerations

CRMi is a presentation layer and takes care not to become a privilege bypass.

·       It declares no permission of its own. Every list, card and count it displays is gated on the native Dolibarr right for the module concerned, checked before the query is run. The applications grid, the notification tray and the global search all filter on both module activation and the user's read right.

·       It creates no table and stores nothing but its own prefixed constants.

·       Output is escaped through Dolibarr's own escaping helpers, and the dashboards and the configuration page are guarded: the layouts refuse to run unless included by the dashboard, and the configuration page refuses any write from a non-administrator server-side, independently of the disabled state of the controls.

·       Forms carry Dolibarr CSRF tokens - the search form, the settings form, the language selector, the configuration import - and the logout link carries one too.

·       Configuration import is validated field by field against the same definition that renders the form, with an unknown key ignored, a bad value skipped, and a size cap on the uploaded file. It cannot write a constant outside the theme's own set.

·       SQL is built with the prefix constant, integer casts on identifiers and the database escaping helper on free text, and every query carries an explicit entity filter, so a multi-entity installation cannot leak figures across entities.

·       The custom dashboard refuses to render when the module is disabled and redirects to the native home page, rather than displaying panels whose chrome no longer exists.

No third-party JavaScript is loaded, no data is sent anywhere outside the installation, and the only optional external request is the web font import, which can be disabled. No independent security audit or penetration test has been carried out on the module.

36 Dolibarr Integration

Every integration point CRMi uses is a documented Dolibarr extension mechanism, and the module modifies no core file.

·       module_parts registers the dynamic stylesheet and script, so they are injected on every page, including pages belonging to other modules.

·       The four forced-menu constants install CRMi's menu manager for both the standard and the smartphone menus. The manager fills its tree from the native menu system with output suppressed, which is why every other module's menu entries and menu hooks keep working.

·       The main hook redirects only the Dolibarr home page to the CRMi dashboard, and only when no other main menu has been requested; it never redirects a page already inside the theme, and the redirect can be disabled entirely.

·       The toprightmenu hook renders the top bar inside the native login block, which is why the bar coexists with whatever else the core or another module puts there.

·       The all hook adds the pre-paint state script to the document head and the print-view rules when Dolibarr's print stylesheet parameter is set.

·       Object links on the dashboards are produced by the core's own link helper, so they carry the standard picto, the standard hover card and the standard permission behaviour.

The consequences are worth stating plainly for an integrator. Any module installed after CRMi appears in the sidebar and, if it is one of the modules CRMi knows, in the applications grid, with no adaptation. Any module that provides a home-page box continues to offer it on the CRMi home page. Any module that hooks the top bar continues to render there. And disabling CRMi returns the installation to its previous menu manager and theme with no residue beyond its own constants.

37 Dolibarr Compatibility

The module descriptor declares a minimum Dolibarr version of 16.0 and a minimum PHP version of 7.0. The code is written to run on PHP 8: it avoids the constructs that break there, and every one of the twenty PHP files passes a syntax check.

What was actually exercised is narrower than what is declared, and the distinction matters when planning a deployment. CRMi was installed, activated and driven through all seven demos on Dolibarr 23.0.3 with PHP 8.1 and MariaDB, on an isolated installation whose custom folder contained only this theme. Dolibarr 20 and 21 were not exercised, and neither were the older releases down to the declared 16.0 minimum.

Buyers running an earlier major version should treat the declared minimum as the developer's intent and validate on a copy of their own installation before deploying. The integration points CRMi uses have been stable across those releases, which is the basis for the declaration, but a declaration is not a test.

Multi-entity installations are supported in the code - every query filters on the entity, the configuration is stored per entity, and the entity switcher appears when more than one entity exists - but the test installation had no Multicompany module, so that path is unexercised.

38 Browser Compatibility

CRMi targets current evergreen desktop and mobile browsers. It relies on CSS custom properties, CSS grid and flexbox, CSS mask images for the wave cut of the gradient sign-in layout, the Fullscreen API and local storage - all long-standing features in current browsers. Vendor-prefixed forms are emitted alongside the standard ones for the mask properties.

Features that may be absent degrade rather than break: the fullscreen control is rendered hidden and is only revealed once the script has confirmed the API exists, and every local storage access is wrapped so that a browser refusing storage loses only the persistence of the light/dark and collapsed states.

Verification was carried out on Chromium only. Firefox, Edge and Safari were not run against the product at the time of writing, and no claim is made about them. Internet Explorer is not supported.

39 Technical Architecture

The architecture has one organising idea: a single resolved preset array is the only thing that decides what the product looks like, and every other file reads it.

core/crmi_presets.php is that source of truth. It is a plain library: it never bootstraps Dolibarr and never prints anything, so it can be included from the dynamic stylesheet and script - which run with the core's no-bootstrap constants set - as well as from the dashboard, the sidebar, the hooks and the configuration page. It declares the seven presets, the palette overrides, the font stacks, and the resolver that applies the administrator's overrides on top of the selected demo. Because the configuration page reads its defaults from the same array as the stylesheet, the two cannot drift apart.

Resolution order for the active demo is: a session-backed preview, then the per-user preference when per-user demos are enabled, then the entity-wide setting, then the default. The resolved array then absorbs the palette override and its derived surfaces, the shape and typography settings, the navigation family, the hero band, the layout, the sidebar and header variants, the effects and the KPI family.

The other components are thin by comparison. css/crmi.css.php emits the two token blocks, the overrides for Dolibarr's standard pages, the chrome, the dashboard components, the five sign-in layouts and the horizontal navigation, then appends the active demo's CSS partial. js/crmi.js.php holds only behaviour - theme toggle, collapse, mobile drawer, menu filter, dropdown management, chart cursor, horizontal menu behaviour - and no strings and no counters. class/actions_crmi.class.php holds the four hooks. core/menus/standard/ holds the menu manager and the sidebar and horizontal renderers. index.php holds the shared data layer and the dispatch; core/crmi_data.php holds the per-demo datasets; core/dashboards/ holds the seven pure layouts.

One further file deserves mention: class/crmi_demo.class.php seeds a representative dataset - customers, a service product, invoices spread over the recent months, orders, proposals in every status and agenda entries - so that a demonstration platform shows a living dashboard. It runs at most once, and only when the platform is explicitly flagged as a demonstration platform; it never runs on a customer installation.

40 Folder Structure

Path

Contents

crmi/index.php

Custom dashboard: shared data layer, helpers and layout dispatch

crmi/search.php

Cross-object global search results page

crmi/setlang.php

Language-selector endpoint (POST, CSRF-checked)

crmi/admin/setup.php

Configuration page, 37 settings, demo gallery, JSON import/export

crmi/class/actions_crmi.class.php

Hooks: redirect, top bar, head script, footer

crmi/class/crmi_demo.class.php

Demonstration-platform data seeder

crmi/core/crmi_presets.php

Preset engine: seven demos, palettes, fonts, resolver

crmi/core/crmi_data.php

Per-demo datasets, guarded by the dashboard constant

crmi/core/dashboards/

Seven pure layout files plus a contract README

crmi/core/menus/standard/

Menu manager, sidebar and horizontal navigation renderers

crmi/core/modules/modCrmi.class.php

Module descriptor, activation and removal

crmi/css/crmi.css.php

Dynamic stylesheet generator

crmi/css/demos/

Seven per-demo CSS partials, one emitted per request

crmi/js/crmi.js.php

Dynamic behaviour script

crmi/langs/

Seven language folders, 491 keys each

 

The archive unpacks to a single crmi/ folder placed under Dolibarr's custom/ directory. Nothing is written outside it, and no file is added to or modified in the Dolibarr core tree.

41 Installation Guide

Standard installation, from the Dolibarr interface:

·       Sign in as an administrator and open Home, Setup, Modules/Applications.

·       Open the Deploy/install external app/module tab and upload module_crmi-1.0.zip. If the tab is absent, the installation forbids web deployment; use the manual method below.

·       Return to the module list, select the Interfaces family, and enable CRMi.

·       Reload any page. The sidebar, top bar and home dashboard are replaced immediately.

·       Open the theme settings - from the module list or from the top-bar user menu - to choose a demo, a palette and the layout options.

Manual installation: unzip the archive so that the files land at custom/crmi/ inside the Dolibarr document root, ensure the web server user can read them, then enable the module as above. The custom directory must be enabled in Dolibarr's configuration file, which is the default.

What activation does: it writes the four forced-menu constants for the current entity, bumps the interface revision so that the new assets are loaded on the next page view, and records its own asset version. It creates no table, adds no permission and touches no business record.

Uninstalling: disable the module. The forced-menu constants and the asset-version marker are deleted, and Dolibarr returns to the menu manager and theme it used before. The theme's settings remain in the constants table, so re-enabling restores the same look; a reset on the configuration page clears them if that is not wanted.

42 Upgrade Guide

·       Take a backup of the database and of the custom/crmi/ folder, as for any module upgrade.

·       Deploy the new archive over the existing folder, or upload it through the deployment tab. Files are replaced in place; no file outside custom/crmi/ is involved.

·       If the module was disabled during the operation, re-enable it. On activation the descriptor compares the shipped version with the recorded asset version and, when they differ, bumps Dolibarr's interface revision so that every user picks up the new stylesheet and script on a normal reload rather than needing a forced refresh.

·       Verify the configuration page. Settings live in the constants table under the theme's own prefix and are preserved across upgrades; a setting removed in a later version simply stops being read.

Because the module creates no table, there is no schema migration and no data conversion at any version. A downgrade is equally simple: deploy the older folder. The configuration export on the settings page provides an additional safety net - exporting the JSON before an upgrade lets an administrator restore the exact look afterwards, or replicate it on a staging instance.

43 Customization Guide

Three levels of customisation are available, in increasing order of commitment.

Configuration only. Demo, palette or custom colours, semantic colours, font, font size, corner radius, gutter, shadows, borders, animations, page layout, sidebar surface and width, header variant, KPI family, navigation family, hero band, and the visibility of each sidebar and dashboard section. This covers the great majority of brand-alignment requests without touching a file, and the result can be exported as JSON and replayed on other instances.

Stylesheet extension. Every component reads the theme's custom properties, so a small additional stylesheet - added through Dolibarr's own custom CSS setting or by an integrator's own module - can restyle any component by redeclaring tokens, without forking anything. This is the recommended route for a client-specific look, because it survives an upgrade.

Source customisation. Adding a demo means adding one entry to the preset array, one CSS partial named after its key, and one layout file in the dashboards folder; the dispatch, the configuration page, the demo gallery and the switcher all enumerate the preset array, so nothing else needs to be edited. The dashboards folder ships a README documenting the contract a layout must respect, including the complete list of variables the data layer provides and the rule that a layout must never run a query. Integrators taking this route should keep their changes in a copy of the folder and re-apply them on upgrade, as with any modified module.

44 Translation System

CRMi ships seven language files, each holding the same 491 keys.

Code

Language

Keys

en_US

English

491

fr_FR

French

491

es_ES

Spanish

491

it_IT

Italian

491

de_DE

German

491

nl_NL

Dutch

491

pt_BR

Portuguese (Brazil)

491

 

The seven files were checked to hold identical key sets with no duplicate key, no mojibake and matching placeholder counts across languages - the three defects that usually reach production in a translated module.

Every key is prefixed with the module name. This is not cosmetic: Dolibarr loads all modules' language files into one namespace, so a generic key such as Status or Total would let another installed module silently override a CRMi label, or the reverse. Prefixing removes the whole class of problem.

Strings added by the top bar and the sidebar go through a helper that falls back gracefully: it tries the CRMi key, then optionally a native Dolibarr key that the core already translates into every language it ships, then a readable English default. A missing translation therefore shows a proper word rather than a raw key. Business vocabulary - status names, document types, module names - is taken from Dolibarr's own translations wherever it exists, so CRMi speaks the same language as the rest of the application.

Adding a language means copying a folder and translating 491 lines; no code change is required. The interface language itself is selected from the top bar, from the full list of languages available in the installation, and stored as a per-user preference.

45 Screenshots Description

The screenshot set that accompanies this product is built to show the seven demos side by side rather than to flatter one of them. The recommended set, and the one used during validation, is as follows.

·       Seven dashboard captures, one per demo, at 1600 by 990 pixels: CRM with its prospect bars and invoice-status columns; Business Analytics with its ring cards, revenue combo and activity timeline; Human Resources with its delta cards, working-format donut and recruitment table; Production with its gradient status card and production-by-unit bars; Project Management with its semicircular gauge, phase badges and overdue-task table; eCommerce with its dark profit panel and best-seller table; Restaurant with its pictogram tiles and stacked daily orders.

·       Two chrome captures: the sidebar expanded and folded, showing the profile card, the menu badges, the favourites and recents sections and the icon-only rail.

·       Two top-bar captures: the notification tray open with real overdue counts, and the user menu open.

·       One configuration capture showing the demo gallery and the five setting groups.

·       One global search capture showing grouped results across object families.

During validation the screenshots were read rather than merely captured: six rendering defects were found by inspecting the images and were fixed before release. That method is worth stating because it is the only one that catches the class of fault where the markup, the HTTP status and the console are all clean and only the picture is wrong.

Captures of the sign-in pages and of the dark-mode variants of all seven dashboards were not part of the validated set at the time of writing; see section 47.

46 Advantages

·       Seven complete demos in one product, switchable in one click, with no re-installation and no data migration - and, because a layout may never run a query, switching changes the arrangement and never the figures.

·       Real figures. Every number is an aggregate of the host database, every KPI links to the native list filtered to the same scope, and the number on the tile matches the total on the list.

·       Explicit degradation. A disabled module produces a written notice, an empty population produces n/a, and a widget with no Dolibarr source is either rebound to a measured quantity and re-captioned or replaced by an explanation. Nothing is simulated.

·       No core modification, no database table, no permission of its own, and a clean removal path. The risk profile of installing this theme is that of installing a stylesheet, not that of forking an ERP.

·       A large configuration surface - 37 settings across five groups, nine palettes plus a custom pair, seven fonts, seven KPI families, seven page layouts - all reading one preset array, so no setting can silently become a no-op, and all exportable as JSON.

·       Full ecosystem compatibility: other modules' menus, hooks and home-page widgets keep working, because CRMi fills its own navigation from the native menu tree and keeps the native widget zone.

·       Seven languages with 491 verified keys each, all prefixed so that no other module can override a label.

·       Accessibility work that is actually in the code: accessible names on every icon control, keyboard-dismissible menus, focus-visible outlines, text alternatives for charts, reduced-motion support, and direction indicated by an arrow as well as by colour.

47 Limitations

This section is deliberately complete. A buyer should be able to read it and be surprised by nothing after purchase.

Not verified at the time of writing. The following were not exercised and no claim is made about them:

·       Dolibarr 20 and 21 were not exercised, and neither were releases down to the declared 16.0 minimum. Validation was carried out on Dolibarr 23.0.3 with PHP 8.1 and MariaDB only.

·       Browser testing was carried out on Chromium only. Firefox, Edge and Safari were not run against the product.

·       The seven sign-in pages were not visually validated. The CSS for all five layouts is written and shipped, but no capture of the rendered pages was inspected.

·       Dark mode was not visually validated across all seven demos. The token sets are complete and the toggle works, but only the top bar was inspected in dark mode.

·       Tablet and smartphone passes over the seven dashboards were not carried out. Horizontal overflow was checked at 1600 pixels and the top bar was inspected at 390 pixels; the breakpoints between those two widths rest on the stylesheet, not on a test.

·       Multi-entity switching is unexercised: the test installation had no Multicompany module, so the entity switcher and cross-entity filtering were not observed in practice.

·       The right-to-left setting, and the dark, coloured and gradient header variants, are implemented but no shipped preset selects them. The same is true of the horizontal navigation family, of the hero band, and of the fifth sign-in layout: all seven shipped presets use vertical navigation with a flat canvas. Those code paths are reachable only by changing a setting and should be validated by the integrator before being put in front of users.

Deliberately omitted controls. Two top-bar controls are not rendered on an installation that cannot support them: the Documents shortcut, which requires the ECM module to be enabled and readable, and the entity switcher, which requires more than one entity. This is a design decision - a control that does nothing teaches users to distrust the whole bar - but an evaluator comparing the product against its screenshots on a minimal installation will notice their absence, and should know why.

Widgets with no Dolibarr data source. The reference designs contained several widgets that no Dolibarr installation can feed. In each case CRMi either rebound the widget to a measured quantity and relabelled it, or replaced it with a written note. Nothing is simulated, but the picture is consequently plainer than the mock-up in these places:

·       Web visitors and site traffic: no source. Not rendered.

·       Customer complaints and star reviews: no source. The eCommerce and Restaurant review panels are replaced by a note stating that Dolibarr stores no ratings or comments and that connecting a review or point-of-sale module would fill the panel.

·       Remote versus on-site working: no flag exists. The HR working-format donut instead splits internal employees from external users, and says so on screen.

·       Staff turnover: no dated departure is recorded, so no rate is derived; the panel states it.

·       Headcount history: Dolibarr keeps none, so the headcount is presented as a live count with a note rather than as a trend.

·       Daily turnover: no daily aggregate exists, so the analytics period boxes show the last closed month, the current period and the year to date instead.

·       Restaurant covers, tables and dine-in versus online: none exist. The tiles present native commerce objects under restaurant labelling with an explicit on-screen statement, and the flow panel compares orders taken with invoices issued.

·       Returns: no return object exists; credit notes are counted instead and the card is labelled for what it counts.

·       Prior-year comparison on the restaurant earnings panel: not part of that dataset, so a single series is drawn and the panel says why.

Environment note. On the PHP built-in development server, a URL with no query string causes Dolibarr's own main include file - which reads the query-string server variable without guarding it - to emit a warning into the page header. This originates in the Dolibarr core, not in CRMi, and CRMi guards its own read of that variable. It is not expected under Apache, nginx or PHP-FPM, although that was not verified.

Known defects at the time of writing. The dashboard footer resolves a module-name translation key belonging to a different module number, which the shipped language files do not define; on an installation where no other module defines it, the raw key is printed in the footer line. The README and CHANGELOG files included in the archive still describe an earlier four-demo iteration of the product and do not match the seven demos delivered. Both are documentation-level defects with no effect on data or behaviour, and both are corrected in the next build.

Finally, two things this product is not. It is not a reporting tool: the dashboards are fixed layouts, not a report designer, and a buyer needing arbitrary user-defined indicators should plan for a reporting module alongside. And it is not a restaurant, e-commerce or HR application: the demos present the data those trades care about, drawn from what Dolibarr actually records, and they do not add the missing business objects.

48 Future Enhancements

The following are candidate developments. None of them is committed to a date, and none should be counted as part of the delivered product.

·       Completion of the validation matrix: visual passes over the seven sign-in pages, dark mode across all seven demos, tablet and smartphone widths, and at least one non-Chromium browser.

·       Validation of the currently unselected code paths - right-to-left, the horizontal navigation family, the hero band, and the dark, coloured and gradient header variants - followed by shipped presets that use them, so that they are exercised by default rather than only by configuration.

·       Testing against the older Dolibarr releases down to the declared minimum, and adjusting the declaration to whatever is actually proven.

·       A multi-entity pass on an installation carrying the Multicompany module, covering the entity switcher and per-entity configuration.

·       User-selectable dashboard panels, so that a user can hide or reorder the theme's own panels the way the native widget zone already allows for core boxes.

·       Additional demos: the preset engine was built so that a new demo is one preset entry, one CSS partial and one layout file, and further trades can be added at that cost.

·       Optional bindings to widely used third-party modules - point of sale, ticketing, e-commerce connectors - so that the panels currently replaced by explanatory notes can be filled with real data when those modules are present.

·       A formal accessibility audit against WCAG 2.1 AA, and an assistive-technology test pass.

49 Support and Maintenance

CRMi is published and maintained by DoliResources. Support requests, defect reports and enhancement requests should be addressed to the editor through the website below, quoting the module version, the Dolibarr version, the PHP version, the active demo and, where the issue is visual, a screenshot.

Because the module creates no table and stores its configuration as prefixed constants, support interventions are low-risk: exporting the configuration as JSON from the settings page gives the editor an exact picture of the deployed look, and importing a corrected file restores it. Where a fault must be isolated, disabling the module returns the installation to its previous theme in one click without touching a business record, which makes it straightforward to establish whether a problem originates in the theme or elsewhere.

Maintenance releases follow the upgrade procedure in section 42: deploy the folder, re-enable if necessary, and the interface revision bump distributes the new assets to every user on their next page load. Settings are preserved across versions.

Editor: DoliResources. Website: https://www.doliresources.com. Copyright: DoliResources. Licence: GPL-3.0-or-later. Document version 1.0.0, 21 July 2026.