Discover powerful Dolibarr extensions designed to automate your business processes
Semidash is a premium interface module for Dolibarr ERP/CRM published by DoliResources. It is not a colour skin applied over the existing screens: it...
Couldn't load pickup availability
Semidash is a premium interface module for Dolibarr ERP/CRM published by DoliResources. It is not a colour skin applied over the existing screens: it is a complete application shell that replaces the navigation rail, the top bar, the home dashboard and the sign-in page, while leaving every business screen, every permission check and every third-party module working exactly as before. The technical name of the module is theme_semidash, it is installed in the folder semidash, its descriptor class is modSemidash, its module identifier is 10000720 and this document describes version 1.0.0, distributed as module_semidash-1.0.zip.
The distinguishing feature of Semidash is that a single package ships six complete, switchable design identities. Each identity, referred to as a demo, carries its own light and dark palettes, its own sidebar and top-bar treatment, its own KPI card family, its own dashboard composition and its own sign-in layout. Switching from one demo to another is a single dropdown in the configuration screen and repaints the entire application in one request, with no re-installation, no file replacement and no loss of configuration.
Every figure displayed by Semidash is read from the operational Dolibarr database. There is no sample data, no placeholder series and no hard-coded number anywhere in the dashboards. Turnover, order counts, proposal pipelines, project progress, agenda occupancy, ticket volumes, campaign statistics and document counts are all computed from the standard tables at page load, filtered by entity and by the signed-in user's permissions.
Semidash never modifies a single file of the Dolibarr core. It uses only the officially supported extension mechanisms: the module_parts declaration for injecting its stylesheet and script, a forced MenuManager for the navigation, and the standard hook system for the remaining chrome. Disabling the module removes the forced menu constants and returns the installation to its previous appearance without touching any business record.
Semidash presents itself in the Dolibarr module list under the Interfaces family, at module position 90. Once enabled, four constants are written that redirect the standard and smartphone menu managers, front and back, to the module's own manager semidash_menu.php. From that moment every page of the application is rendered inside the Semidash shell, whichever module produced its content.
The shell is composed of four elements. A vertical navigation rail on the left carries the brand, a user profile block, a module filter field, a bookmark section, the permission-filtered navigation tree with live counter badges, a recently-opened list and a footer showing how many modules are active. A top bar spans the remaining width and carries the global search field, the light and dark theme toggle, the native Dolibarr login block and the quick-action icons. The content area below hosts either the Semidash dashboard or the unmodified page produced by Dolibarr. A restyled sign-in page completes the set.
The theme is delivered as a small, self-contained tree: a module descriptor, a preset engine, a dynamic stylesheet, a dynamic script, a hook class, a menu manager and its rendering library, the dashboard, a global search page, a configuration screen, an optional demonstration data seeder and seven language files. There is no build step, no compiled asset and no external runtime dependency; the stylesheet and the script are PHP files that read the active configuration and emit exactly the rules the active demo needs.
The declared compatibility floor is Dolibarr 16.0 and PHP 7.0, with the module developed and validated against recent 17.x and 22.x releases. It declares no dependency on any other module and no conflict with any other module.
Semidash was designed against five explicit objectives, each of which constrained the implementation in a concrete way.
· Restore visual hierarchy. Standard Dolibarr screens present information at a nearly uniform typographic weight. Semidash establishes a deliberate scale in which headline figures, panel titles, secondary labels and metadata are visually distinct, so that the most important number on a screen is the first one read.
· Make the interface addressable. A user must be able to reach any record in the system without navigating a tree. This produced the global search page, the module filter in the rail, the bookmark section and the recently-opened list.
· Show real operational data on the home page. A dashboard populated with sample figures is worse than no dashboard, because it teaches users to distrust the screen. Every panel therefore queries the live database and every panel that cannot query, because its module is disabled, says so explicitly.
· Ship variety without shipping weight. Six design identities in one package must not mean six stylesheets parsed on every request. The preset engine and the conditional emission of the stylesheet ensure that a page rendered in the Default demo never downloads the Material elevation rules, and a page rendered with horizontal navigation never downloads the vertical rail geometry.
· Never fork the core. Every behaviour is obtained through a declared module_parts entry, a forced menu manager or a registered hook. This guarantees that a Dolibarr minor upgrade cannot silently break the theme and that a support engineer can always reason about a Semidash installation as a standard Dolibarr installation with one extra module.
A sixth, transverse objective governed the configuration surface: no setting may become a dead control. Wherever an administrator override could leave a design token pointing at a value from a different demo, the preset engine recomputes the dependent tokens so the change is visibly complete.
The interface follows a card-and-panel model. Content is grouped into surfaces that carry a background, a radius, an optional border and an optional shadow, all derived from the same set of design tokens. Because the tokens are emitted once at the top of the stylesheet and consumed everywhere else, the visual system remains coherent even when an administrator changes the corner radius, the base font size or the gutter width.
Interaction is designed around recognition rather than recall. The navigation rail keeps the active module and the active sub-entry highlighted, using an identifier carried in the URL rather than a fragile path comparison, so a collapsed module never lights up by accident and the active module remains marked even when the destination page rewrites its own query string. Counter badges attached to navigation entries give an immediate sense of pending work without requiring the user to open the module first.
Empty states are treated as first-class content rather than as an error path. A panel whose underlying module is disabled renders an icon, a title and an explanatory sentence telling the user which module would populate it. A panel whose module is enabled but which has no rows renders a neutral no-data state. In neither case is a PHP notice, a zero-filled chart or a broken layout ever shown.
Motion is used sparingly and is always optional. Transitions are limited to hover feedback and panel entry; they can be switched off globally from the configuration screen, which makes the interface immediately usable on low-powered terminals and for users who find animation distracting.
Finally, the theme respects the user's own choices. The light and dark preference and the collapsed or expanded state of the rail are stored per browser and survive navigation, while the demo, the palette and the structural settings remain the administrator's responsibility.
The Default demo, stored under the key default, is the identity Semidash installs with. It pairs a dark navy navigation rail with a light top bar and a soft blue-grey application background, and it drives the eCommerce dashboard.
Its palette is built on a primary blue, a lighter blue secondary, a cyan accent, a green success tone, a coral danger tone and an amber warning tone. In dark mode the surfaces move to deep navy while the primary and the semantic colours are retained, so the demo remains recognisable in either scheme. The rail is 224 pixels wide, corners are drawn at a 10 pixel radius and the typeface is Inter.
The KPI card family is tint: a white card is topped by a pastel band coloured with the card's own tile colour, and the icon sits in a white bubble on that band. Four tile colours are cycled across the KPI row, giving each metric a stable identity across page loads. Chart series use a five-colour ramp beginning with cyan and the primary blue.
The sign-in layout is split: a full-height gradient panel occupies the left 46 percent of the viewport and the sign-in card is aligned to the right. Below 900 pixels the panel collapses into a 220 pixel header band and the card centres itself, so the identity survives on a phone.
The Default demo is the recommended starting point for distribution, commerce and general-purpose installations. It is the most conservative of the six: the dark rail reads as familiar to users coming from the standard Dolibarr menu, while the card treatment and the dashboard composition deliver the visual upgrade.
The Minimal demo, key minimal, is the lightest identity in the package. Both the navigation rail and the top bar are white, the application background is white rather than tinted, and separation between regions is carried by hairline borders instead of shadows or colour blocks.
Its palette is a soft sky blue primary with a teal accent, an orange danger tone and a yellow warning tone. The rail is 232 pixels wide, corners are drawn at a tight 8 pixel radius and the typeface is Inter. In dark mode the demo moves to a near-black canvas with the same sky-blue primary, producing a high-contrast, low-chrome result.
The KPI card family is outline: cards are drawn with a visible border and no fill, the metric is carried by typography rather than by a coloured surface, and the accent appears only in the delta indicator and the icon. This is the most information-dense of the six card families and is the reason the Minimal demo is paired with the Analytics dashboard, where a large number of measures must coexist without competing for attention.
The sign-in layout is minimal: a flat canvas, a borderless card and a single coloured rule across the top edge of the card. There is no gradient panel and no decorative geometry.
Minimal is the appropriate choice for installations where the interface must recede behind the data, for users who spend long uninterrupted sessions in the application, and for organisations whose own brand guidelines forbid strong chrome.
The Material demo, key material, is the most structured identity. It applies a coloured navigation rail painted in a deep indigo, with the active entry inverted to a white surface carrying indigo text, under a light top bar.
The palette is built on a deep indigo primary with a lighter indigo secondary, a periwinkle accent, a green success tone, a red danger tone and a gold warning tone. The rail is deliberately narrow at 150 pixels, corners are drawn at a compact 6 pixel radius and the typeface is Roboto, which together with the elevation treatment produces the recognisable material vocabulary.
The KPI card family is material: cards rely on elevation and a clearly delineated icon container rather than on tints or outlines. The tile ramp opens on green and periwinkle rather than on the primary, which keeps the indigo rail from dominating the whole screen.
The sign-in layout is card: the gradient fills the entire page and the sign-in card floats on top of it with a deep drop shadow and no border. In dark mode the card is repainted with the dark surface token so it does not glare against the gradient.
Material drives the CRM dashboard, whose pipeline funnel, lead breakdown and deal table benefit from the strong separation between panels. It suits sales organisations and any deployment where several users share screens during meetings, since elevation reads more reliably than tint at a distance and under projection.
The Elegant demo, key elegant, is the only identity in the package that abandons the vertical navigation rail. Its navigation orientation is horizontal: the same permission-filtered menu tree is re-laid-out as a full-width bar positioned directly beneath the top bar, and second-level entries become drop-down panels opened on hover on pointer devices and on tap elsewhere.
Because the tree itself is unchanged, every module's entries, every counter badge and every translation behave identically to the vertical presentation. Elements that belong to the rail rather than to the tree, namely the brand row, the profile block, the module filter, the section labels and the collapse control, are hidden in horizontal mode because the top bar already carries their function. The content area then sits below both bars instead of beside a rail, and the rail width token is forced to zero.
The palette departs sharply from the rest of the package: a lime primary with a cyan accent, a teal success tone and an amber warning tone, over a white rail and a dark top bar. Corners are drawn at a generous 12 pixel radius and the typeface is Poppins.
The KPI card family is geometric, built on rotated shapes and angular accents. The sign-in layout, named panel, extends the same language: two large rotated squares filled with the demo gradient at low opacity sit behind a centred card on a light canvas.
Elegant drives the Projects dashboard. The horizontal navigation frees the full viewport width for Gantt-adjacent content, task tables and team panels, which is precisely where a vertical rail costs the most.
The Flat demo, key flat, pairs a near-black navigation rail with a light top bar and a neutral grey application background. It is the most graphic of the six identities and the one that leans hardest on flat colour.
The palette is built on an indigo-violet primary with a violet accent, a green success tone, a soft red danger tone and an amber warning tone. The rail is narrow at 150 pixels, corners are drawn at a 10 pixel radius and the typeface is Poppins.
The KPI card family is flat: solid colour fields with no gradient, no elevation and no outline, relying entirely on hue and typographic weight for hierarchy. This makes the KPI row read as a single deliberate band of colour rather than as four separate objects, which is the effect the media dashboard is built around.
The sign-in layout is centered: a soft tinted halo sits behind a centred card and a thin gradient rule crosses the top of the viewport, echoing the application top bar.
Flat drives the Media dashboard, which presents document volumes, content tables, audience curves and creator rankings drawn from the electronic content management tables and the user table. The identity suits agencies, publishers, communication departments and any installation where the electronic content management module is a primary workload rather than an accessory.
The Creative demo, key creative, is the warmest identity in the package. A dark charcoal navigation rail sits under a light top bar, and the palette is built on a coral primary with a soft teal accent, a periwinkle secondary tone, a mint success tone and a warm yellow warning tone.
The rail is the widest of the six at 250 pixels, corners are drawn at a generous 12 pixel radius and the typeface is Nunito Sans. The combination of wide rail, large radius and humanist typeface produces a noticeably softer result than the other five demos.
The KPI card family is soft: cards carry a low-opacity tint derived from their own tile colour, rounded icon containers and no hard borders. Chart series open on coral and teal.
The sign-in layout is hero: the demo gradient occupies the top 46 percent of the viewport with a large bottom radius, and the sign-in card straddles the boundary between the coloured region and the page background.
Creative drives the Healthcare dashboard. It is important to state plainly what that means. Dolibarr has no medical record model, so the Healthcare dashboard maps clinical vocabulary onto generic Dolibarr objects: third parties stand for patients, agenda events stand for appointments, users stand for practitioners and products stand for supplies. The presentation is appropriate for clinics, practices, care networks and associations that already run their activity on those generic objects; it is not, and does not claim to be, a clinical information system.
The dashboard is a single file, index.php, that resolves the active demo, computes every dataset once, and then renders one of six mutually exclusive presentations. Access to it is obtained by a hook on the main context that redirects the Dolibarr home page to the module dashboard; that redirection can be switched off entirely from the configuration screen, in which case the standard Dolibarr home page is restored while the rest of the shell remains.
Execution proceeds in four stages. The bootstrap stage loads Dolibarr, resolves the reporting period from the request, which may be week, month or year, and determines the reference year, the number of elapsed months and the comparison boundaries. The data stage runs the queries, each guarded by a module-enabled test. The geometry stage converts the resulting series into drawing instructions. The rendering stage emits the markup for the active demo.
All chart geometry is produced in PHP and emitted as inline SVG. There is no charting library, no canvas element and no client-side rendering pass. The file contains a small set of primitives that convert a numeric series into a smoothed path, an area fill, a bar group, a stacked bar group, an arc, a meter, a funnel, a radar or a Sankey diagram. Because the output is SVG, charts scale cleanly, print correctly and remain legible in dark mode without a second code path.
Common helpers handle the operations that recur across all six presentations: monetary formatting through the Dolibarr price function so the installation's own currency and separators are respected, period-over-period delta computation returning both a signed value and a display string, relative time formatting, safe scalar extraction from a query, and object link generation that always routes through the core path builder rather than a hard-coded URL.
The KPI row is the first element of every dashboard and always contains four cards. The markup of a card is identical in all six demos, which means a widget never has to know which identity it is being rendered in; only the stylesheet differs. Each card carries a label, a formatted value, a delta indicator comparing the current period with the previous one, an icon, a tile colour drawn from the demo's four-colour KPI ramp, a destination URL and a descriptive tooltip.
The entire card is clickable through a stretched anchor overlay, so the target of a metric is always the corresponding Dolibarr list, pre-filtered where the core supports it. The expected earnings card leads to the invoice list, the orders card to the order list, the new clients card to the customer list filtered on customer types, and the growth card back to the dashboard in yearly mode.
|
Demo |
KPI family |
Visual treatment |
|
Default |
tint |
White card, pastel top band in the tile colour, icon in a white bubble |
|
Minimal |
outline |
Bordered card, no fill, colour restricted to delta and icon |
|
Material |
material |
Elevated card, delineated icon container, no tint |
|
Elegant |
geometric |
Angular accents and rotated shapes |
|
Flat |
flat |
Solid colour field, no gradient, no elevation |
|
Creative |
soft |
Low-opacity tint derived from the tile colour, rounded containers |
The KPI family normally follows the demo, but an administrator can force one of four alternative families, segment, solid, widget or minimal, independently of the chosen demo. This is the mechanism by which an installation can keep the Material palette and layout while adopting a lighter card treatment, or the reverse.
The vertical rail is produced by the module's own menu manager, which fills its tree from the native Dolibarr menu system by calling the standard menu builder in silent mode. This is the architecturally decisive choice: every module's entries, every permission filter and every menu hook continue to apply, because Semidash never enumerates menu items itself, it only re-renders the tree the core produced.
From top to bottom the rail carries the brand and logo row, an optional user profile block, a module filter field that narrows the tree as the user types, a bookmark section fed by the Dolibarr bookmark system with an add-current-page control, the navigation tree, a recently-opened list and a footer.
Navigation entries at the first level can carry a live counter badge, for example unpaid invoices, open proposals or events due today. The badge map is built by a small set of guarded queries; a module that is disabled is simply absent from the map, so a badge is never a stale or meaningless number. Badges can be hidden globally from the configuration screen.
Active-state resolution deserves particular mention. Each sub-entry is given a stable identifier composed of the module key and its sequence in the tree, and that identifier is appended to the link. The rendered page therefore knows exactly which entry produced it, even when the destination page rewrites its own query string, which is the usual cause of an active state that silently disappears.
The footer shows how many modules are active out of the total, linking to module management, and carries the collapse control. Collapsing narrows the rail to an icon strip; the state is stored per browser. Below 760 pixels the rail leaves the flow entirely and becomes an off-canvas drawer opened from the top bar.
Horizontal navigation is the Elegant demo's native orientation and can be forced on or off for any demo from the configuration screen through a three-valued setting: follow the preset, force vertical or force horizontal.
In horizontal mode the navigation container is repositioned as a fixed full-width bar 48 pixels high, anchored immediately below the top bar. The rail-specific elements are suppressed, the tree is laid out as a horizontally scrollable row of first-level entries, and second-level entries are presented as drop-down panels 236 pixels wide anchored under their parent. Third-level entries open to the side rather than pushing the panel downward, and panels near the right edge of the viewport are flipped to align on their right edge so they cannot overflow the window.
Drop-down panels open on hover on devices that report hover capability and on click elsewhere; both paths converge on the same open-state class that the sidebar script already toggles, so no separate mobile code path exists. When horizontal navigation is active the preset engine forces the rail width token to zero and disables the start-collapsed behaviour, so no residual gutter remains beside the content.
The honest limitation of this mode is that it reuses the same menu tree rather than presenting a bespoke mega-menu with grouped columns and promotional panels. This is a deliberate trade-off: reusing the tree is what guarantees that a newly installed third-party module appears in the horizontal bar automatically, with its permissions and its translations intact.
The top bar is a fixed band spanning the width available beside the rail, or the full width in horizontal mode. It is assembled partly in PHP by the menu manager and partly by the injected script, which relocates the elements Dolibarr itself renders rather than duplicating them.
· A menu button, shown at narrow widths, which opens the navigation drawer.
· The global search field, which submits to the module's dedicated search page. The placeholder and the button label are translated server-side and passed to the script, so no user-visible string is hard-coded in JavaScript.
· The light and dark theme toggle, which writes the choice to browser storage and applies it by setting a data attribute on the document element and on the body.
· The native Dolibarr login block, comprising the user menu, the bookmark star, the entity selector where multi-company is active and the module-provided top-right entries. This block is preserved and restyled rather than replaced, so every third-party module that adds an icon there keeps working.
· A quick-actions cluster contributed by the module's hook on the top-right menu context, which can be hidden globally from the configuration screen.
The theme applied on the very first paint is decided server-side by an inline script emitted in the HTML header on every request. This avoids the flash of an incorrect scheme and, more subtly, ensures that the cached copy of the injected script cannot override the freshly rendered state: the script reads the attribute already present on the document element rather than a value baked into itself.
The global search page is a dedicated screen that queries eight object families in parallel and presents the results as a grid of grouped cards. Each group carries an icon, a colour drawn from the active demo's tokens, a result count, up to six result rows and a link that opens the corresponding Dolibarr list pre-filtered on the same term.
|
Family |
Fields searched |
Permission required |
|
Third parties |
Name, alias, customer code, town, e-mail, phone |
societe.lire |
|
Contacts |
Last name, first name, e-mail |
societe.contact.lire or societe.lire |
|
Products and services |
Reference, label |
produit.lire or service.lire |
|
Invoices |
Reference |
facture.lire |
|
Proposals |
Reference |
propal.lire |
|
Orders |
Reference |
commande.lire |
|
Projects |
Reference, title |
projet.lire |
|
Users |
Login, last name, first name, e-mail |
administrator or user.user.lire |
Each group is queried only when the signed-in user holds the corresponding right, so search results can never disclose the existence of a record the user is not entitled to see. Every query is bounded by the entity filter returned by the core, which makes the page correct in multi-company installations, and every term is escaped through the database abstraction layer before interpolation.
Result rows are enriched to be useful without opening them: a third party shows its customer code, town and e-mail; a product shows its formatted price; an invoice, proposal or order shows the third party and the total including tax. Rows carry either a two-letter initial badge or a coloured dot, depending on whether an initial is meaningful for that family.
Two empty states are distinguished. When no term has been entered the page invites a search and explains what can be searched. When a term returns nothing the page states the term that failed and suggests broadening it.
The CRM dashboard is the presentation attached to the Material demo. It is organised around the commercial pipeline and the customer relationship rather than around financial totals.
Its principal panel is a sales pipeline funnel built from the proposal table. Five stages are counted and valued independently: leads, proposals issued, signed, billed and pending. Each stage contributes both a record count and a total amount including tax, and each is coloured from the demo's chart ramp. Because the stages are derived from the proposal status field rather than from a custom pipeline model, the funnel reflects the installation's real commercial process without configuration.
· A total-messages panel summarising agenda and communication volume.
· An industry leads breakdown grouping customers by their recorded classification.
· A customer overview panel combining new customer counts with growth against the previous period.
· A recent deals table listing the most recent commercial documents with their third party, amount and status.
Where the proposal module is disabled, the funnel panel is replaced by an explanatory empty state naming the module that would populate it, rather than by an empty chart. The remaining panels degrade individually in the same way, so the dashboard remains coherent on an installation that runs only part of the commercial suite.
The CRM presentation is the appropriate default for sales-led organisations, and it is the presentation that benefits most from the counter badges in the navigation rail, since a commercial user typically wants to know how many proposals are awaiting a response before deciding where to click.
The Project dashboard is attached to the Elegant demo and is rendered under horizontal navigation, which gives it the full viewport width.
Project data is read from the project and task tables, joined to third parties and users. One implementation detail is worth recording because it affects correctness across versions: the project table in Dolibarr 17 carries no responsible-user column, so the project leader is resolved through the element-contact table filtered on the internal PROJECTLEADER contact type, with the project creator used as a fallback. The dashboard therefore names a leader for every project rather than leaving the column blank on older schemas.
· An income-per-project panel, computed from invoices carrying a project reference, using the turnover base and status filter configured for the installation.
· A project statistics panel and a project overview table listing reference, title, third party, leader, start and end dates and opportunity amount.
· A task panel counting total, running, completed and late tasks. A task is late when it has an end date in the past and a progress below one hundred percent.
· A personal task list ordered so that dated tasks come first, nearest deadline first, with undated tasks last.
· A team members panel and a meetings panel fed from the agenda.
· A task performance chart summarising completion against planned workload and effective duration.
When the project module is disabled the entire dashboard body is replaced by a single explanatory panel naming the module, which is more useful than six independently empty widgets.
The Analytics dashboard is attached to the Minimal demo and is the densest of the six. It is built for users who read trends rather than individual records.
Its central element is a growth analysis chart plotting the current period against the comparable previous period. Around it sit a conversion rate panel, a sessions and conversions comparison, a campaign performance panel fed from the mailing module, a marketplace sales panel and an audience overview.
The monthly order series is a good illustration of how the dashboard handles real data. Orders are grouped by month and by status for the reference year, then distributed into three parallel series: requested orders at status zero, cancelled orders at status minus one, and all remaining statuses treated as validated. The series are sized to the number of elapsed months rather than to a fixed twelve, so a chart drawn in March shows three columns rather than three columns and nine empty ones.
The campaign performance panel reads the mailing table together with a correlated count of successfully sent targets, giving a genuine delivery figure rather than the nominal recipient count. When the mailing module is disabled the panel renders an explanatory empty state naming it.
The audience overview groups customers by country through a join on the country dictionary, producing a ranked list of the top eight countries with their share of the total. On an installation where no third party has a country recorded, the panel explains that rather than drawing an empty map.
The eCommerce dashboard is attached to the Default demo and is the presentation most installations will see first. It is organised around the sales cycle from product to payment.
Its KPI row carries expected earnings, orders in the current month, new clients and monthly growth, each with a period-over-period delta and each linking to the corresponding list. Below it, a sales overview chart plots turnover across the reference period, accompanied by a compact customer growth panel.
· A top-selling products panel built from order lines, aggregating quantity and turnover per product across all orders in the entity, ranked by quantity.
· A product stock panel listing sellable products ordered by ascending stock, so items closest to depletion appear first, with the configured stock alert threshold available for comparison.
· A top countries panel derived from the customer country distribution.
· A product statistics panel, a customer support panel fed from the ticket module and a recent activity feed.
The turnover figures respect two configuration settings that materially change their meaning. The turnover base can be set to amounts including tax or excluding tax, and abandoned invoices can be included in or excluded from the total. Both settings are exposed in the configuration screen with an explanatory hint, because a turnover figure whose basis is ambiguous is worse than no figure at all.
The customer support panel counts open tickets, those below the closed status, separately from closed ones. Where the ticket module is disabled, the panel names it in an empty state rather than reporting zero tickets, which would be misleading.
The Media dashboard is attached to the Flat demo and is built around content rather than around transactions. Its data comes principally from the electronic content management file table and from the user table.
The dashboard reports a total document count for the entity and lists the most recently created documents with their filename, path, creation date, sharing status and the type of object they are attached to. A user growth curve, an audience statistics panel, an international listening panel, a listened-time panel, a top creators ranking and a popular content table complete the presentation.
The media player element appears only when the underlying content management contains files that can actually be played. On an installation whose document store holds only invoices and contracts, the player is absent and the surrounding panels reflow to fill the space; no disabled control and no broken player frame is ever rendered. This is stated explicitly here because it is a behaviour users notice and ask about.
Where the document table is empty the popular content table renders a dedicated empty state that names documents specifically, rather than the generic no-data state, so an administrator understands that the panel is waiting on the content management module rather than on a query failure.
The Media presentation suits agencies, publishers, internal communication teams and any organisation whose document volume is a meaningful operational indicator in its own right.
The Healthcare dashboard is attached to the Creative demo. It presents a care-oriented reading of standard Dolibarr objects and its scope must be understood precisely.
Dolibarr ships no clinical data model. The Healthcare dashboard therefore maps medical vocabulary onto generic objects: third parties are presented as patients, agenda events as appointments, users as practitioners and products as supplies. The dashboard is a presentation layer, not a medical records system, and it stores no clinical information of any kind.
· A patient overview panel derived from the third-party population and its growth.
· A book-appointment panel and a doctor schedule panel fed from agenda events, ordered by scheduled date with events from the last three days retained so a recent appointment does not vanish from the list.
· A fund allocation panel presenting the distribution of financial flow across the reference period.
· A vaccination statistics panel, presented as a proportional measure over the population.
· A medicine supplies panel drawn from the product table, which names the product module explicitly in its empty state when that module is disabled.
· A satisfaction rate gauge and a patient list table.
The presentation is genuinely useful for clinics, practices, care networks and health-sector associations that already manage their activity through third parties, agenda and products in Dolibarr. It is not appropriate as a substitute for a certified clinical information system, and no claim to that effect is made anywhere in the product.
Beyond the KPI row, the dashboards are assembled from a common vocabulary of widget primitives. Each primitive takes a dataset and returns markup; none of them contains a hard-coded value or a sample series.
· Panel. The base surface, carrying a head with a title and optional actions, and a body. Every other widget lives inside one.
· Table. A compact tabular list with a fixed header and per-column alignment, used for products, projects, deals, documents, patients and team members.
· List item. A row combining an initial badge or coloured dot, a primary label, a secondary line and a trailing value or chevron.
· Meter. A single horizontal progress measure with a percentage and a colour.
· Gauge. A circular arc rendering a percentage, used for satisfaction and completion measures.
· Sparkline and micro bars. Compact series drawn without axes, used inside cards.
· Empty state. An icon, a title and an optional explanatory sentence.
The final section of every dashboard is a widgets area that hosts the native Dolibarr boxes, including database statistics and open account balances, restyled to match the active demo. This preserves the value of any box a third-party module contributes. The area can be hidden entirely from the configuration screen for installations that prefer a purely Semidash home page.
All widgets share the same tokens for radius, gutter, border presence and shadow depth, so an administrator changing the gutter from twenty-four to sixteen pixels sees a uniformly tighter dashboard rather than a mixture of spacings.
All charts are generated server-side as inline SVG. No charting library is loaded, no canvas is used and no client-side rendering pass takes place. This has four consequences that matter operationally: charts appear in the first paint rather than after a script executes, they scale without blurring, they print correctly, and they inherit the theme tokens so dark mode requires no second code path.
|
Primitive |
Purpose |
|
Smoothed line |
Trend curves, turnover and growth series |
|
Area |
Filled variant of the line, used for emphasis on a primary series |
|
Grouped bars |
Monthly order counts split by status |
|
Stacked bars |
Composition of a total across categories |
|
Arc and meter |
Percentage gauges and single progress measures |
|
Funnel |
Commercial pipeline by stage |
|
Radar |
Multi-axis comparison |
|
Sankey |
Flow between two sets of categories |
Series colours come from the active demo's five-colour chart ramp, and semantic colours for success, danger and warning remain individually overridable by the administrator whatever demo or palette is in force. When a palette override is applied, the ramp's second slot is repointed at the new primary so a recoloured installation does not display a chart in the previous demo's colours.
Numeric axes are computed from the actual data range rather than from a fixed scale, and series are sized to the number of elapsed periods rather than padded to a full year. Monetary values pass through the Dolibarr price formatter, so the installation's currency, thousands separator and decimal separator are respected throughout.
Semidash restyles the standard Dolibarr list and table components in addition to providing its own. This matters more than the dashboard for daily use, because a Dolibarr user spends most of their time in list views.
Core list tables receive the theme's typography, row height, border treatment and hover feedback. Header cells, sort indicators, pagination controls, the mass-action bar and the filter row are all brought into the token system. Status badges are recoloured to the theme's semantic tones while retaining the meaning the core assigns them, so a user's learned association between colour and status is preserved.
Dashboard tables follow the same visual rules but are built for density: a fixed header, compact rows, right-aligned numeric columns and a trailing action affordance. Every row that represents a Dolibarr record links to that record through the core path builder, never through a constructed path, so a non-standard installation directory cannot break the links.
Long tables are constrained so they scroll within their own container rather than forcing the page to scroll horizontally. This is a deliberate correction of a common failure mode in wide list views, where a single long column pushes the entire layout sideways and hides the navigation.
Where a table has no rows, the empty state is rendered inside the table body spanning the full column count, so the header and the surrounding panel geometry are preserved and the table does not visibly collapse.
Form controls throughout the application are brought into the theme's token system. Text inputs, number inputs, selects, textareas, checkboxes, radios, date pickers and the enhanced select components used by the core all receive the theme's border colour, radius, background surface, text colour and font stack.
Focus is treated as a first-class state rather than as a browser default. A focused control receives the primary colour on its border together with a soft ring drawn from the primary tint, and the native outline is suppressed only after that replacement is in place. The result is a focus indicator that is more visible than the browser default, not less, which matters for keyboard navigation.
Buttons follow the semantic palette: primary actions use the demo's primary colour with a matched drop shadow, cancel and secondary actions use a neutral surface, and destructive actions use the danger tone. Hover feedback is a brightness change and a one-pixel lift, both suppressed when animations are disabled.
The configuration screen is itself an example of the form treatment. Settings are grouped into five labelled sections, each with an icon, a title and a subtitle; each row carries a label, an optional explanatory hint and its control aligned to the right. Colour settings pair a native colour picker with the current hexadecimal value displayed alongside it, so an administrator can read the value without opening the picker.
On a demonstration platform the configuration form is rendered for any signed-in user so the module can be evaluated, but the save and reset controls are shown disabled and every write is additionally refused server-side. The visual affordance and the security boundary are enforced independently.
The sign-in page is restyled in full and carries a distinct layout for each of the six demos. This is architecturally the most constrained surface in the theme, and the constraint shapes the implementation.
The sign-in page is pre-session. There is no browser storage to read, no user preference to honour and no pre-paint script yet. The active demo is therefore resolved entirely server-side from the stored configuration, which is exactly the correct behaviour for a page shared by every user of the installation.
A shared base first normalises the page: the core's diagonal two-tone background is reset, the form is presented as a single card with the theme's radius, border and shadow, the nested panel the core draws inside the form is flattened so no card-within-a-card appears, the field pictograms are suppressed because they misalign full-width controls, the entity selector is stretched to match the inputs, and error messages are recoloured to the danger tone. In dark mode the supplied logo, which is dark blue and nearly invisible on a navy card, is inverted to white rather than being given a light backing plate.
|
Demo |
Layout |
Treatment |
|
Default |
split |
Full-height gradient panel on the left, card aligned right |
|
Minimal |
minimal |
Flat canvas, borderless card, single coloured rule on top |
|
Material |
card |
Gradient fills the page, card floats with a deep shadow |
|
Elegant |
panel |
Two rotated squares in the demo gradient behind a centred card |
|
Flat |
centered |
Tinted halo behind a centred card, thin gradient rule across the top |
|
Creative |
hero |
Gradient occupies the top 46 percent, card straddles the boundary |
All six layouts are drawn using pseudo-elements on the markup Dolibarr already emits. No additional element is injected into the sign-in DOM, which is owned by the core and must not be fought. Below 520 pixels every layout falls back to a padded centred card.
The interface is usable from 390 pixels upward, which covers current mainstream phones in portrait orientation, and it is designed for that width rather than merely tolerating it.
|
Breakpoint |
Behaviour |
|
Above 1400 px |
Full multi-column dashboard, all panels side by side |
|
1400 px |
Widest dashboard grids reduce their column count |
|
1200 px |
Secondary panel columns collapse into the primary flow |
|
1100 px |
Two-column and eleven-column grids become single column |
|
1024 px |
Horizontal navigation relaxes its fixed height and stops clipping |
|
960 px |
Native box columns stack vertically |
|
760 px |
Navigation rail becomes an off-canvas drawer; dashboard fully single column |
|
600 px |
Search result grid becomes single column; search field height reduced |
|
520 px |
Sign-in card padding reduced, layout decorations simplified |
Below 760 pixels the rail is taken out of the document flow, positioned at full viewport height and translated off-screen; a state class on the application wrapper slides it back in. Because it is a transform rather than a width change, the transition is smooth on mobile hardware and the content does not reflow while the drawer opens.
Wide content is contained rather than allowed to escape. Tables, chart containers and code-like content scroll inside their own region, so the page body never scrolls horizontally. This is enforced at the primitive level, which means a third-party module rendering an unusually wide table inside a Semidash panel is contained automatically.
The dashboard grids are declared in terms of minimum column widths rather than fixed column counts, so panels reflow at whatever width their content actually requires instead of snapping at a small number of arbitrary breakpoints. The named breakpoints above are therefore corrections applied where automatic reflow alone gives a poor result, not the primary layout mechanism.
Charts adapt without a second code path, because they are SVG with a declared view box: the same markup that fills a wide panel on a desktop scales down cleanly inside a single-column phone layout, with no re-render and no request. Typography and spacing follow the configured base font size and gutter at every width, so an installation running the compact layout mode remains compact on mobile rather than reverting to default spacing.
Dark mode is implemented for all six demos, not as a global inversion but as a second complete palette declared per demo. Each preset carries a light block and a dark block covering background, three card surfaces, three text levels, two border levels and the full set of sidebar and top-bar tokens.
The mechanism is a data attribute on the document element and on the body. The stylesheet declares its tokens once for the light scheme and redeclares the affected tokens under the dark attribute selector; every rule elsewhere in the stylesheet consumes tokens rather than literal colours, so the entire interface, including the dashboards, the charts, the sign-in card and the restyled core screens, follows automatically.
The initial scheme is decided in three stages. An inline script emitted in the HTML header on every request sets the attribute before first paint, using the demo's own default or the administrator's dark-by-default setting. The injected script then reads that attribute as its baseline rather than a value compiled into itself, which prevents a cached copy of the script from reverting a freshly changed demo. Finally, if the user has made an explicit choice on this browser, that choice takes precedence.
One interaction is worth documenting because it looks like a bug otherwise. Changing the demo in the configuration screen clears the browser's stored light or dark preference, because a preference recorded under the previous demo would silently mask the new demo's own default and make the setting appear to have done nothing.
A small number of elements receive explicit dark-mode treatment because token substitution is not sufficient for them: the supplied logo on the sign-in page is inverted, and the sign-in card is repainted with the dark surface on the gradient-backed layouts so it does not glare.
All configuration is performed on a single screen reached from the module list or from the top bar. Settings are grouped into five sections: Demo, Appearance, Layout, Menu and Dashboard. The screen opens with a gallery of demo cards, each painted in that demo's own five principal colours, each carrying its name and description, and each offering a preview link.
|
Group |
Settings |
|
Demo |
Demo selection, palette, KPI card style, dark mode by default |
|
Appearance |
Primary, accent, success, danger and warning colours; font family; corner radius; base font size; web font loading |
|
Layout |
Layout mode; navigation orientation; sidebar style; header style; shadow depth; borders; gutter; animations; right-to-left |
|
Menu |
Rail width; hide profile; hide counter badges; hide call to action; hide bookmarks; hide recents; maximum recents; hide top actions |
|
Dashboard |
Disable the dashboard redirection; hide native boxes; annual target year; turnover base; include abandoned invoices |
The layout mode offers fluid, boxed, compact and full. Compact is not merely a width change: it reduces the gutter by eight pixels and the base font size by one point, producing a genuinely denser interface. The sidebar style offers preset, light, dark, coloured, floating, mini and large; the coloured variant repaints the rail in the primary colour and rewrites its text, hover and active tokens so contrast remains correct. The header style offers preset, gradient, light, dark, transparent and coloured.
Two guarantees are built into the engine. First, the default value of every setting is read from the preset definition itself, so a reset can never restore a palette that differs from the one the stylesheet ships. Second, saving or resetting increments the core's interface revision counter, which is embedded in the stylesheet and script URLs; without that increment a demo change would remain invisible for up to an hour behind the one-hour cache header.
Semidash distinguishes between administrator settings, which are stored in the Dolibarr constants table and apply to the whole entity, and user preferences, which are stored in the browser and apply to that browser only. The distinction is deliberate: an organisation's visual identity is an administrative decision, while comfort settings belong to the individual.
· Light or dark scheme. Stored under a dedicated key, applied by setting the data attribute on the document element, and toggled from the top bar. It overrides the demo's default until the demo is changed.
· Collapsed or expanded navigation rail. Stored under a separate key and restored on every page load, so a user who prefers the icon rail keeps it across sessions.
· Open or closed state of navigation groups, which follows the active module so the branch containing the current page is expanded.
Two further personalisation mechanisms are not browser-stored but genuinely per-user, because they rest on Dolibarr's own data. Bookmarks are read from the core bookmark system, so a user's favourites are their own and follow them to any browser; the rail offers a control that adds the current page to them without leaving it. The recently-opened list is recorded as the user navigates and is capped by an administrator-configurable maximum, five by default.
Administrators can suppress any of these surfaces globally. The profile block, the counter badges, the call-to-action button, the bookmark section, the recents section and the top-bar quick actions each have a dedicated hide setting, which allows the shell to be reduced to navigation alone where an organisation prefers a minimal chrome.
Accessibility work in version 1.0 concentrated on the areas where a restyled interface most commonly regresses: focus visibility, contrast and motion.
Focus is never removed without replacement. Text inputs, password fields and selects, in the application and on the sign-in page, receive the primary colour on their border together with a three-pixel soft ring in the primary tint; the native outline is suppressed only in the same rule that introduces the replacement. The result is a focus indicator with a larger visual footprint than the browser default.
Contrast is managed at the token level rather than per component. Each demo declares three text levels and three surface levels for light and for dark, and the sidebar override logic actively protects contrast: forcing a dark rail onto a demo whose rail is white replaces the text and hover tokens with a safe pair rather than leaving dark text on a dark surface, and the coloured rail variant rewrites all five of its child tokens rather than only its background. This class of defect, a label rendered in a colour that is now invisible against a changed background, is the most common failure in configurable themes and is guarded against explicitly.
Motion is controllable. A single administrator setting disables transitions and animations across the entire interface, which serves users sensitive to motion as well as low-powered terminals. Interactive chrome carries descriptive title attributes, the disabled controls on the configuration screen are marked with the appropriate ARIA disabled state, and decorative gradients and shapes are drawn with pseudo-elements so they are absent from the accessibility tree.
The honest position for version 1.0 is that these are WCAG-oriented practices rather than a certified conformance claim. A full audit against WCAG 2.1 level AA, including a systematic ARIA labelling pass over the custom navigation chrome and honouring the reduced-motion media query in addition to the administrator toggle, is planned and is listed among the future enhancements.
Semidash adds two assets to a Dolibarr page: one stylesheet and one script. Both are PHP files, and both are designed so that the cost of the theme is bounded and predictable.
The stylesheet emits only what the active configuration needs. The KPI card family, the sign-in layout and the navigation geometry are all conditional blocks: a page rendered in the Default demo never downloads the Material elevation rules, and a page rendered with horizontal navigation never downloads the vertical rail geometry. This is what allows six complete identities to ship in one package without six stylesheets being parsed on every request.
Both assets are served with a one-hour cache header and carry the core's interface revision in their URL. Saving the configuration, resetting it or enabling a new version of the module increments that revision, so users receive the new assets on an ordinary reload rather than needing a forced refresh, while steady-state traffic is served from cache.
Both assets bootstrap Dolibarr with the no-requirement constants set, so they skip the society, menu, HTML and Ajax initialisation that a full page needs. The preset engine is deliberately a plain library that never bootstraps Dolibarr and never prints anything, which is what allows it to be shared unchanged between the stylesheet, the script, the dashboard, the rail and the configuration screen.
On the dashboard, every dataset is computed once before rendering and reused across panels, queries are bounded by explicit limits, aggregate figures are obtained through single scalar queries rather than by counting rows in PHP, and every query is guarded by a module-enabled test so a disabled module costs nothing. Chart rendering is pure string construction with no image generation and no external process.
Semidash presents data that already exists in Dolibarr; its security posture is therefore concerned with not weakening the guarantees the core provides.
· Permission filtering. Every dashboard dataset and every global search group is gated on the signed-in user's rights, evaluated through the core's own right-checking API. A user without invoice rights sees no invoice figures and no invoice search results; the panels are absent rather than empty.
· Entity isolation. Every query is bounded by the entity filter returned by the core for that object type, which makes the module correct in multi-company installations. The user table is additionally scoped to the shared entity and the current one.
· Input handling. Request parameters are read through the core's sanitising accessor with an explicit type. The search term is escaped through the database abstraction layer before interpolation, numeric identifiers are cast, and the demo preview parameter is reduced to lowercase letters and then validated against the list of known preset keys, so an unknown value can never reach the rendering path.
· Output handling. User-supplied and database-supplied strings are escaped with the core's HTML tag escaper before printing throughout the dashboard, the search page and the configuration screen.
· Write protection. The configuration screen refuses access to non-administrators, and refuses any action to non-administrators even on a demonstration platform where the read-only view is permitted. Saves are protected by the core's anti-forgery token and the reset action carries a token in its URL.
The module registers a content security policy hook. Because the theme optionally imports web fonts from a public font service, an installation operating under a strict policy should either allow that origin or disable web font loading in the configuration screen, in which case the theme falls back to the system font stack and makes no external request at all.
Semidash integrates through four officially supported mechanisms and no others.
The first is the module_parts declaration, which registers the stylesheet and the script so the core injects them into every page, and registers the module's menu directory so the forced manager can be located. The second is the forced menu manager: four constants redirect the standard and smartphone managers, front and back, to the module's own manager. The third is the hook system, with the module registering on the main, all, top-right menu and search form contexts. The fourth is the configuration page declaration, which places the module's settings screen in the module list.
The hook class performs four functions: it contributes to the content security policy, it adds entries to the top-right menu, it emits the pre-paint theme script and the theme's header markup, and it closes the shell in the common footer. The redirection of the home page to the module dashboard is performed on the main context and is subject to the administrator's disable setting.
The decisive integration decision is that the navigation tree is not enumerated by Semidash. The menu manager calls the core menu builder in silent mode and re-renders the tree it returns. Consequently every third-party module's entries appear automatically, permission filtering is the core's own, menu hooks from other modules continue to fire, and a module installed after Semidash requires no action to appear in the navigation.
Similarly, the native login block in the top bar, including the user menu, the bookmark star, the entity selector and any icons contributed by other modules, is preserved and restyled rather than replaced. The native dashboard boxes are hosted in the dashboard's widgets area rather than discarded.
The module declares a minimum Dolibarr version of 16.0 and a minimum PHP version of 7.0. It has been developed and exercised against the 17.x and 22.x lines and is designed to remain forward-compatible with subsequent releases, because it depends on interfaces rather than on internals.
Version differences in the database schema are handled explicitly where they exist. The clearest example is the project leader: the project table in Dolibarr 17 carries no responsible-user column, so the leader is resolved through the element-contact table filtered on the internal project-leader contact type, with the project creator as a fallback. Writing the query that way makes it correct on both older and newer schemas rather than correct on one and blank on the other.
Two defensive measures protect activation. The administration library that provides the constant-setting functions is not auto-loaded by the core; it happens to be present during a web request, so a module that relies on its presence fails only when enabled from a command-line script, and fails fatally. The descriptor therefore requires it explicitly before use. Separately, the module tolerates its own configuration object being absent during early bootstrap by initialising it in the constructor.
The module declares no dependency and no conflict. In practice, the one genuine incompatibility is structural rather than declared: two theme modules that both force a menu manager cannot be active simultaneously, since the last one enabled wins the constants. Administrators should enable one interface theme at a time.
Deactivation is clean. The removal routine deletes the four forced menu constants and the asset version marker, so the installation returns to its previous theme and a later re-enable correctly bumps the cache revision again. No business data is read, written or deleted at any point in the module lifecycle.
Semidash targets current versions of the mainstream browsers: Chrome and Chromium-based browsers including Edge, Firefox, and Safari on macOS and iOS. The interface is built on widely supported platform features rather than on polyfills.
The layout relies on CSS grid and flexbox, the theming system on custom properties, the charts on inline SVG, and the preference storage on the browser's local storage API. All four have been broadly available for several years across every targeted engine.
Two features are used where they degrade gracefully rather than break. Colour mixing in the search page's group icons falls back to the plain accent colour where unsupported, leaving the icon legible. Hover-capability detection is used to decide whether horizontal drop-downs open on hover, with the click path always available as the baseline, so a device that reports no hover capability retains full navigation.
Internet Explorer is not supported and no attempt is made to support it; it lacks custom property support, which is foundational to the entire theming system. Dolibarr itself no longer targets it.
Printing is supported implicitly rather than through a dedicated stylesheet: because charts are SVG rather than canvas or bitmap, dashboard output prints at the printer's resolution rather than at the screen's. A dedicated print stylesheet that suppresses the navigation chrome is listed among the future enhancements.
The architecture rests on one principle: a single source of truth for the design, consumed by every renderer.
That source is the preset engine, a plain PHP library that never bootstraps Dolibarr and never prints. It exposes the six preset definitions, the palette overrides, the font stacks, a configuration reader that works even under partial bootstrap, a resolver for the active preset key, a resolver for the fully applied preset, and three colour utilities that convert to hue-saturation-lightness, build translucent variants and blend toward white or black.
The resolver is where the design is actually decided. It takes the preset for the active key and applies every administrator override in a defined order: palette, then semantic colours, then shape and typography, then layout and chrome variants, then navigation orientation, then effects, then KPI family. Critically, when a palette override is applied it repoints every derived token, the active sidebar colour, the top-bar background, the first KPI tile, the first chart slot and the sign-in gradient, because a token left pointing at the previous demo's colour is a dead setting that makes a change look partially applied.
Because the stylesheet, the script, the dashboard, the rail and the configuration screen all call the same resolver, three properties follow. A demo switch is total, since no renderer holds its own copy of the design. A reset cannot restore a stale palette, since the configuration screen reads its defaults from the same array the stylesheet ships. And no setting can silently become a no-op, since every consumer sees the resolved value.
The demo preview is the one place where request state enters the resolution. A preview key supplied in the query string is validated, then memoised in the PHP session; the reasoning is set out in the following section on installation and in section 30.
A note on that memoisation belongs here as well. Dolibarr emits the module stylesheet as a fixed link element whose URL the module cannot extend, so a query-string-only preview would repaint the PHP-rendered markup while the stylesheet continued to serve the stored demo, producing the right layout in the wrong palette, and would not change the sign-in page at all, since its appearance is entirely CSS-driven. Writing the choice to the session makes the very next stylesheet request resolve to the same demo, so the preview is complete and instantaneous. A reset value clears it.
The module is a flat, readable tree of nineteen files. There is no build artefact, no vendored dependency and no generated code.
|
Path |
Role |
|
core/modules/modSemidash.class.php |
Module descriptor: identity, module_parts, forced menu constants, activation and removal |
|
core/semidash_presets.php |
Preset engine: the six demos, palettes, fonts, resolver, colour utilities |
|
core/menus/standard/semidash_menu.php |
Menu manager registered as the forced manager |
|
core/menus/standard/semidash.lib.php |
Rail rendering: brand, profile, filter, bookmarks, tree, badges, recents, footer |
|
css/semidash.css.php |
Dynamic stylesheet, emitting only the active demo's rules |
|
js/semidash.js.php |
Dynamic script: top bar assembly, theme toggle, collapse, drawer |
|
class/actions_semidash.class.php |
Hook class: security policy, top-right menu, header, footer |
|
class/semidash_demo.class.php |
Optional demonstration data seeder, used only on a demonstration platform |
|
index.php |
The six dashboards and all their queries and chart primitives |
|
search.php |
Global search across eight object families |
|
admin/setup.php |
Configuration screen |
|
langs/<code>/semidash.lang |
Seven language files |
|
README.md, CHANGELOG.md |
Package documentation |
The tree is installed under the custom directory so that files land at custom/semidash. No file is written outside that directory at any point, and the module creates no directory of its own.
Two properties of the layout are worth drawing out, because they explain why the module is small relative to what it does. The first is that the design lives in exactly one file. The preset engine holds every colour, every geometry value and every variant name for all six demos; the stylesheet, the script, the dashboard, the rail and the configuration screen contain no design constants of their own, only consumption of the resolved preset. Adding a demo therefore touches one array rather than five files.
The second is that the dashboard is one file rather than six. Because all six presentations share the same query stage, the same chart primitives and the same widget vocabulary, index.php computes every dataset once and then emits one of six mutually exclusive rendering blocks. A change to how turnover is computed, or to how a smoothed line is drawn, applies to all six dashboards at once and cannot drift between them.
The naming convention follows Dolibarr's own: the descriptor is prefixed with mod, the hook class with actions, the menu manager matches the constant that forces it, and every language key, CSS class and configuration constant carries the module prefix. This is what allows Semidash to coexist with other modules in the merged language and stylesheet namespaces without collision.
Installation follows the standard Dolibarr procedure for an external module and requires no shell access.
· Navigate to Home, then Setup, then Modules and Applications, and open the tab for deploying an external application or module.
· Upload the package module_semidash-1.0.zip. Dolibarr extracts it into the custom directory.
· Locate Semidash in the Interfaces family and enable it. Enabling writes the four forced menu constants and increments the interface revision so the new assets are fetched immediately.
· Open the configuration screen, from the cog beside the module entry or from the top bar, and choose a demo.
For a manual installation, extract the archive so that the files land at custom/semidash, with the web server user able to read them, then enable the module from the module list as above. The custom directory must be enabled in the Dolibarr configuration file, which is the default in standard installations.
Before committing to a demo, use the preview links in the configuration gallery. A preview opens the dashboard with the demo parameter appended, repaints the entire theme for the current session including the stylesheet and the sign-in appearance, and leaves the stored configuration untouched. Appending the reset value returns to the configured demo. This is the safe way to compare all six identities on real data before deciding.
No database table is created, no schema is altered and no business record is written. On a demonstration platform only, and only once, an optional seeder may populate sample records; this path is inert on a normal installation and is guarded by both a platform constant and a one-time marker.
Upgrading Semidash is a file replacement followed by a module refresh. Configuration is stored in the Dolibarr constants table and is not touched by an upgrade, so the demo, palette and every override survive.
· Take a backup of the database and of the custom/semidash directory, as for any module change.
· Deploy the new package through the same external-module screen, or replace the directory contents manually.
· Disable and re-enable the module from the module list. Re-enabling rewrites the forced menu constants and, when the shipped version differs from the recorded asset version, increments the interface revision.
· Confirm that the dashboard, the navigation rail and the sign-in page render as expected, in both light and dark schemes.
The asset revision mechanism is what makes an upgrade invisible to end users. Both the stylesheet and the script are served with a one-hour cache header and carry the interface revision in their URL; because activation bumps that revision when the version changes, users load the new files on an ordinary reload rather than needing a forced refresh, and no support request about a half-updated interface arises.
When upgrading Dolibarr itself rather than the theme, no Semidash action is normally required, because the module depends on public interfaces rather than on core internals. The prudent check after a major Dolibarr upgrade is that the navigation rail still renders every module's entries, since that is the surface most exposed to a change in the core menu builder.
To roll back, restore the previous directory contents and disable and re-enable the module. Configuration constants are compatible in both directions within the 1.x line.
Semidash offers three levels of customisation, in increasing order of effort and decreasing order of upgrade safety.
The first level is the configuration screen, which covers the great majority of requirements: demo, palette from nine presets or a custom pair, five semantic colours, six font families, corner radius, base font size, layout mode, navigation orientation, seven sidebar variants, six header variants, shadow depth, borders, gutter, animations, right-to-left, rail width and the visibility of every optional rail and top-bar surface. Nothing at this level is lost on upgrade.
The second level is the Dolibarr constants table. Every setting is a plain constant with a documented name beginning with the module prefix, so an installation that provisions its environments through scripts can set them directly without visiting the configuration screen. The one obligation is to increment the interface revision afterwards, or the change will remain behind the asset cache for up to an hour.
The third level is editing the preset engine to add a seventh demo or to alter a shipped one. A preset is a self-contained array describing the palette for both schemes, the sidebar and top-bar variants, the navigation orientation, the dashboard key, the rail width, the KPI family, the tile, tint and chart ramps, the radius, the font and the sign-in layout. Adding a key to that array makes the new demo appear in the configuration gallery automatically, since the gallery is generated from the array. A new demo that reuses an existing dashboard key and an existing KPI family needs no other change; a genuinely new dashboard or card family additionally requires a conditional block in the dashboard and in the stylesheet. Changes at this level are overwritten by an upgrade and should be maintained as a patch.
For installation-specific cosmetic overrides that must survive upgrades, the recommended route is Dolibarr's own custom stylesheet setting, applied after the module stylesheet, targeting the theme's tokens rather than its individual rules.
All user-visible text is translated through the Dolibarr language system. The module ships a single language file per locale, loaded under the module domain, and every key is prefixed with the module name.
The prefixing is not cosmetic. Dolibarr merges language domains, so a generic key defined by one module can silently render another module's text in an unrelated screen. Prefixing every key eliminates that class of defect entirely.
|
Language |
Keys |
Status |
|
French |
481 |
Complete |
|
English |
481 |
Complete, and the fallback source |
|
Spanish |
481 |
Complete |
|
Italian |
481 |
Complete |
|
German |
481 |
Complete |
|
Dutch |
295 |
Partial: new version 1.0 keys fall back to English |
|
Brazilian Portuguese |
295 |
Partial: new version 1.0 keys fall back to English |
This is stated plainly rather than presented as seven complete languages. Dutch and Brazilian Portuguese carry 295 of the 481 keys; the keys introduced in version 1.0, principally those for the six demos, the six dashboards and the newer configuration settings, are absent from those two files and are resolved by Dolibarr's English fallback. A user working in Dutch will therefore see a fully Dutch navigation and configuration screen with some English labels on the newer dashboard panels. Completing both files is a priority for the next release.
Strings used by the injected script are not hard-coded in JavaScript. They are translated server-side when the script is generated and passed into it, which is why the top bar's placeholder, button labels and toggle tooltip follow the user's language like the rest of the interface.
Adding a language requires only a new directory under langs with a copy of the English file translated in place; no code change is needed.
The following views constitute the documentary set for the module and correspond to the material supplied with the package.
· Default demo, eCommerce dashboard, light. The dark navy rail on the left, the light top bar with the global search field, the four tint KPI cards with their pastel bands, the sales overview curve and, below, the top-selling products and stock panels.
· Minimal demo, Analytics dashboard, light. The white rail against the white canvas separated only by a hairline, the outline KPI cards, the growth analysis chart and the dense lower grid of conversion, campaign and audience panels.
· Material demo, CRM dashboard, light. The indigo rail with its inverted active entry, the elevated KPI cards and the sales pipeline funnel with its five valued stages.
· Elegant demo, Projects dashboard, light. The horizontal navigation bar under the top bar with a drop-down panel open, the full-width content area, the geometric KPI cards and the project overview table.
· Flat demo, Media dashboard, light. The near-black narrow rail, the solid-colour flat KPI band, the user growth curve and the popular content table.
· Creative demo, Healthcare dashboard, light. The wide charcoal rail, the soft coral-tinted KPI cards, the appointment schedule and the satisfaction gauge.
· Dark mode, shown on the Default and Material demos, demonstrating that surfaces, text levels, borders, charts and the sign-in card all follow the second palette.
· The six sign-in layouts: split, minimal, card, panel, centered and hero.
· The configuration screen, showing the demo gallery with its coloured swatch cards and the five grouped setting sections.
· The global search page with several result groups populated.
· Mobile views at 390 pixels: the dashboard in a single column and the navigation drawer open over the content.
The commercial and operational case for Semidash rests on six points.
· Six identities in one purchase. An organisation is not committed at purchase time to a look it may outgrow; the demo dropdown repaints the entire application, including the sign-in page, in a single request.
· Real data throughout. Every figure on every dashboard is queried from the operational database at page load, filtered by entity and by permission. There is no sample data anywhere in the product.
· No core modification. Only declared module_parts entries, a forced menu manager and registered hooks are used, which means a Dolibarr minor upgrade cannot silently break the theme, and a support engineer can reason about the installation normally.
· Automatic coverage of third-party modules. Because the navigation is re-rendered from the core menu tree rather than enumerated, a module installed after Semidash appears in the navigation, with its permissions and translations, without any action.
· Honest degradation. Every panel whose module is disabled says which module would populate it. No error, no zero-filled chart and no broken layout is ever shown as a result of a disabled module.
· Bounded performance cost. One stylesheet and one script, both emitting only what the active configuration needs, both cached for an hour and both revision-busted automatically on change, with all charts rendered server-side as SVG and no charting library loaded.
Two further points matter to administrators specifically. Configuration is a single screen with five grouped sections and an explanatory hint on every setting that needs one, and deactivation is genuinely clean: the forced constants are removed, the previous appearance returns and no business data is touched at any point.
The following limitations are stated deliberately and without qualification, so that expectations are set correctly before purchase and deployment.
· Horizontal navigation reuses the vertical menu tree. The Elegant demo lays the same permission-filtered tree out as a bar with drop-down panels; it is not a bespoke mega-menu with grouped columns, promotional panels or curated ordering. This is the price of guaranteeing that every third-party module appears automatically.
· The Healthcare dashboard maps onto generic objects. Dolibarr has no clinical data model, so third parties stand for patients, agenda events for appointments, users for practitioners and products for supplies. It is a presentation layer for organisations already working that way, not a clinical information system, and it stores no medical data.
· Dutch and Brazilian Portuguese are incomplete. Both carry 295 of 481 keys; the keys introduced in version 1.0 fall back to English through Dolibarr's own mechanism. Users of those two languages will see some English labels on the newer dashboard panels.
· The media player appears only when playable files exist. On an installation whose document store contains only invoices and contracts, the player is simply absent from the Media dashboard rather than shown disabled.
· Accessibility is WCAG-oriented, not certified. Focus replacement, contrast-safe token substitution and a global motion toggle are implemented; a systematic ARIA labelling pass over the custom navigation chrome, and honouring the reduced-motion media query in addition to the administrator setting, are not yet complete.
· Two forcing themes cannot coexist. Any other module that forces a menu manager will conflict, because the last one enabled owns the constants. Only one interface theme should be active at a time.
· Right-to-left support is a layout setting rather than a fully audited mode; bidirectional text within charts in particular has not been exhaustively validated.
· There is no dedicated print stylesheet in version 1.0. Charts print well because they are SVG, but the navigation chrome is not suppressed on print.
· Dashboard composition is fixed per demo. Panels cannot yet be reordered, resized or hidden individually by an end user; only the whole native boxes area and the whole dashboard can be switched off.
The following items form the published roadmap for the 1.x line. They are stated as intentions, not as commitments to a date.
· Complete the Dutch and Brazilian Portuguese language files to full parity, and evaluate additional locales based on demand.
· A user-arrangeable dashboard, allowing panels to be reordered, resized and individually hidden, with the arrangement stored per user rather than per entity.
· A dedicated mega-menu for horizontal navigation, built as an optional layer over the existing tree so that automatic third-party coverage is preserved for installations that do not curate it.
· A full WCAG 2.1 level AA audit with remediation, including a systematic ARIA labelling pass over the custom chrome and support for the reduced-motion media query alongside the administrator toggle.
· A print stylesheet that suppresses navigation chrome and optimises panel pagination, so a dashboard can be circulated as a document.
· Additional demos, which the preset engine already accommodates without structural change; a new preset key appears in the configuration gallery automatically.
· Export of dashboard panels to image and to spreadsheet, for inclusion in periodic reporting.
· A per-user demo preference, allowing individuals to choose an identity within a set the administrator permits, rather than the entity-wide setting of version 1.0.
· Extension of the global search to additional object families, including tickets, contracts and shipments, each gated on its own permission.
· A configurable widget for annual target tracking, building on the existing target-year setting.
Semidash is published and maintained by DoliResources. Support, documentation and updates are provided through the editor's site at https://www.doliresources.com.
The module is distributed under the GNU General Public Licence, version 3 or later, consistent with Dolibarr itself. Customers may inspect and modify the source; modifications to the preset engine or to the dashboard are overwritten by an upgrade and should be maintained as a patch, as described in the customisation section.
When reporting an issue, the following information allows it to be reproduced quickly: the Dolibarr version, the PHP version, the Semidash version, the active demo key, any non-default configuration settings, the browser and version, and whether the behaviour occurs in both light and dark schemes. A screenshot is decisive for rendering issues, since a substantial class of theme defects is visible only in a rendered page and not in any log.
The recommended first diagnostic step for an appearance that seems not to follow a configuration change is the asset cache. Both the stylesheet and the script are served for one hour and carry the interface revision in their URL; saving the configuration increments that revision automatically, but a manually written constant does not, and a hard refresh will confirm or exclude the cache immediately.
Maintenance releases within the 1.x line preserve configuration constants in both directions, so an upgrade or a rollback is a file operation followed by a module refresh. Compatibility with new Dolibarr releases is validated on each major core version, with particular attention to the navigation tree, which is the surface most exposed to change in the core menu builder.
