Administration

Administration pages belong to the super admin with the default seed (cahier §3 « Accès total, paramétrage global, rôles, permissions et audit »). Every change made here is audited (AUD-01). The most sensitive changes ask for re-authentication (confirmations).

ID	Screen	Section	Template	Release	Design	Build
BO-61	Users	Administration	template	V1	Day 19	DSH-12
BO-62	Roles & permissions matrix	Administration	bespoke	V1	Day 19	DSH-12
BO-63	Activity log	Administration	template	V1	Day 19	DSH-12
BO-64	Business settings	Administration	template	V1	Day 19	DSH-12
BO-65	Reference lists	Administration	template	V1	Day 19	DSH-12
BO-66	Mobile app versions	Administration	template	V1	Day 19	DSH-12
BO-67	Data imports	Administration	template	V1	Day 19	DSH-12
BO-68	My profile & sessions	Administration	template	V1	Day 19	DSH-12
BO-70	Support regions & WhatsApp numbers	Administration	template	V1	Day 19	DSH-12

BO-61 — UsersCopy Anchor Link

Purpose. Manage staff and delegate accounts: create them with roles, deactivate them without deleting their history, reset passwords and revoke sessions (cahier §10). Reseller accounts are managed in the CRM, not here.

Who uses it. Super admin.

Entry points. Administration › Utilisateurs, and links from the activity log (actor).

Layout.

• Filters: q, type, role, status.
• Drawer « Nouvel utilisateur »:
  • Prénom and Nom: required.
  • Email: required for staff, unique.
  • Téléphone: unique, E.164.
  • Rôles: multi-select of the six staff roles, at least one. Delegates are created in BO-18.
  • Langue.
  • Envoyer les accès: by email and/or SMS, with a temporary password.
• Row actions: « Modifier », « Réinitialiser le mot de passe », « Sessions », « Suspendre » / « Réactiver », « Désactiver ».

Data. admin.users.list, admin.users.create, admin.users.update, admin.users.setStatus, admin.users.resetPassword, admin.users.sessions, admin.roles.list.

Actions.

Rules.

• A user cannot suspend, disable or remove roles from themselves.
• The last active super admin cannot be suspended, disabled or demoted (409).
• Disabling keeps every record the user created or validated (orders confirmed, audits).

Real-time. None.

States. A suspended user's row is muted with the reason in a tooltip. An SMS or email sending failure shows « Accès non envoyés — Renvoyer ».

Acceptance criteria.

• A new user receives the temporary password and must change it at first sign-in.
• Suspending a user signs them out at their next request.
• Disabling the last super admin is impossible.
• Each role change appears in the activity log as PERMISSION_CHANGE with before and after.

BO-62 — Roles & permissions matrixCopy Anchor Link

Purpose. Edit which actions each role may perform on each module (cahier §3.1 « Les permissions sont gérées par action : voir, créer, modifier, supprimer, valider, exporter et administrer »), with guard rails, a clear view of sensitive permissions, and a diff before saving. The back-office navigation, the visible fields and every API operation follow these permissions (ACL-05).

Who uses it. Super admin. Others with roles.view can read it.

Entry points. Administration › Rôles et permissions.

LayoutCopy Anchor Link

• Left, the roles list: the eight system roles (RoleKey), with label, user count and « Modifié le ».
  • SUPER_ADMIN is marked « Accès total — non modifiable ».
  • DELEGATE and RESELLER are marked « Rôle applicatif — périmètre fixe ». Their permissions are read-only here: their access is defined by the delegate and self scopes.
• Right, the matrix of the selected role:
  • Rows are the 18 modules (dashboard, crm, field, catalog, pricing, stock, orders, delivery, finance, promotions, loyalty, support, communication, reports, users, roles, audit, settings), with their French labels.
  • Columns are the seven PermissionAction values (Voir, Créer, Modifier, Supprimer, Valider, Exporter, Administrer).
  • A cell is a checkbox. Combinations absent from the permission catalogue (admin.permissions.list) are greyed « — ».
  • Row and column headers have « tout cocher / décocher » toggles.
  • Hover help per cell: what the permission allows, in one sentence, with the main screens. Example: « Valider · Commandes : confirmer, refuser et confirmer pour le revendeur toutes les commandes (BO-41) ; dérogations stock et crédit ».
• Sensitive permissions carry a warning icon and a legend:

• « Comparer les rôles » (?compare=1): modules in rows, roles in columns, for one chosen action, or a compact « V C M S Va E A » letter grid per cell. Read-only.
• Save bar: « 3 permissions ajoutées, 1 retirée · Voir le détail · Annuler · Enregistrer ». « Voir le détail » lists each change with its sensitivity flag.

ActionsCopy Anchor Link

RulesCopy Anchor Link

• Guard rails (also enforced by the server):
  • SUPER_ADMIN always holds every permission. It cannot be edited, and roles.administer cannot be removed from it.
  • DELEGATE and RESELLER permissions are fixed.
  • At least one active user must keep roles.administer and users.administer.
• Dependencies: any action implies Voir on the same module. Ticking Créer ticks Voir; unticking Voir unticks the row, after a confirmation tooltip.
• No custom roles in V1: the eight system roles are fixed (RoleKey). There is no « Nouveau rôle ». Users may hold several staff roles, and their permissions are the union.
• Effect:
  • The server checks permissions on every request, so changes apply at the next call.
  • The back-office shell refreshes me.get on focus and every 5 minutes. Navigation and fields update without a new sign-in (see BO-03).
• Data scope (zones, assigned resellers, own data) is not a permission and does not appear here (ACL-03).
• Concurrency: the role carries version. A concurrent edit gets 409 VERSION_CONFLICT and the diff against the newer version.
• Defaults: the seed shipped with the system is described in Sections visible by role. The authoritative matrix is SRS › Permissions matrix.

Data. admin.roles.list, admin.permissions.list, admin.roles.updatePermissions.

Real-time. None.

States.

• Read-only mode (roles.view only): the checkboxes are disabled and the save bar is hidden.
• Unsaved changes: leaving or switching role asks « Abandonner les modifications ? ».
• Guard-rail refusal: the server message is shown inline on the offending cell.

Acceptance criteriaCopy Anchor Link

• Removing crm.view from Administrateur commercial hides the CRM group for its users within 5 minutes, and the CRM API answers 403 PERMISSION_DENIED for them immediately (cahier §12 « Un utilisateur ne peut pas accéder aux fonctions non autorisées »).
• Granting pricing.view to a role makes the purchase-price fields appear for its users. Removing it removes them from both the UI and the API responses.
• Removing orders.validate from every role except super admin leaves the BO-41 queue usable only by the super admin.
• The super-admin row cannot be changed, and an attempt through the API is refused.
• Each save creates one PERMISSION_CHANGE audit entry listing the added and removed permissions.
• Ticking Valider · Commandes also ticks Voir · Commandes.

BO-63 — Activity logCopy Anchor Link

Purpose. Search the activity journal: logins, creations, modifications, validations, exports, deletions, permission changes and overrides, with user, time and context (cahier §3.1 « Toute action critique est historisée avec utilisateur, date, heure et contexte », §10).

Who uses it. Super admin, and direction on request.

Entry points. Administration › Journal d'activité, and the « Historique » links that open it filtered.

Layout.

• Filters: actor, action (multi), entityType, entity (number or id), app, from / to (required; default last 7 days; at most 92 days), q.
• Drawer: every field, and the before/after values as a field table (changed fields highlighted).

Data. admin.audit.list.

Actions. « Exporter » (audit.export) is itself audited EXPORT. The journal is read-only.

Rules.

• Entries are immutable. Retention follows the policy agreed with HOCO (SEC-08).
• OVERRIDE entries (order confirmation despite failed controls) carry the failed controls and the reason.

Real-time. None.

States. A range over 92 days is refused with « Période limitée à 92 jours ».

Acceptance criteria.

• Confirming an order with an override produces VALIDATE and OVERRIDE entries with the actor, the reason and the order number.
• A customer-type change shows before and after values.
• Filtering by entity CMD-2026-000158 returns its full history across actors and apps.

BO-64 — Business settingsCopy Anchor Link

Purpose. The business parameters (cahier §8, ADM-03): order minimums, reservation status, GPS tolerance and frequency, credit policy, stacking, payment methods, delivery fees, and the V1 additions. Many are still open decisions, which is why they are settings.

Who uses it. Super admin. Managers read it.

Entry points. Administration › Paramètres, and the « Paramètre » links on other pages.

Layout. Groups in a left anchor navigation, each a card with its own « Enregistrer » and « Modifié par … le … ». The keys are indicative; the settings catalogue in the SRS is authoritative.

Data. admin.settings.get, admin.settings.update.

Actions.

• « Enregistrer » per group. It is validated by the server and audited UPDATE with before and after values.
• Changes with operational impact ask for confirmation and re-authentication: GPS tolerance, payment methods, credit policy, stock reservation status. For example: « Passer la tolérance GPS de 150 m à 300 m ? Les prochains check-ins seront évalués avec la nouvelle valeur. »

Rules.

• Settings apply to new events only. For example, a new tolerance does not re-evaluate past check-ins, and new delivery fees do not change submitted orders.
• No setting can enable automatic order confirmation or show stock quantities to resellers (§1b.1–2).

Real-time. None.

States. Read-only for settings.view. Validation errors are shown inline per field.

Acceptance criteria.

• Changing Tolérance de check-in to 200 m makes the next delegate check-in at 180 m succeed, and the audit shows before and after.
• Disabling Crédit removes it from every reseller's checkout options.
• The settings page offers no option for automatic confirmation or quantity display.

BO-65 — Reference listsCopy Anchor Link

Purpose. Edit the reference lists used in forms and reasons (cahier §6.5, §6.8; ADM-05).

Who uses it. Super admin.

Entry points. Administration › Listes de référence.

Layout.

• Left, the lists (ReferenceItem.listKey): BUSINESS_TYPE (Types de commerce), PERSON_ROLE (Fonctions), VISIT_NOT_DONE_REASON, VISIT_ISSUE_TAG, TOUR_SUSPEND_REASON, ORDER_REFUSAL_REASON, ORDER_CANCEL_REASON, PAYMENT_REJECT_REASON.
• Right, the items table: Libellé (FR), Libellé (AR) and Libellé (EN) (prepared), Code (stable, UPPER_SNAKE, immutable), Commentaire obligatoire (for « Autre »), Ordre (drag), Actif, Utilisations.
• Links: potentials, ticket types and after-sales issues are enums, translated in the apps. Visit types are edited in BO-26, carriers in BO-43.

Data. admin.referenceLists.crud. The apps read reference.lists, cacheable.

Actions. Add, edit, reorder (optimistic) and deactivate items. All are audited.

Rules.

• Items in use are never deleted, only deactivated. Deactivated items still display on past records.
• Changes reach the apps at their next fetch (ETag) and the delegate app through sync.delta.

Real-time. None.

States. The seeded items are listed. Assumption — the seed labels are to validate with HOCO.

Acceptance criteria.

• A new refusal reason appears in the BO-39 refusal dialog.
• A deactivated reason is no longer offered but still shows on orders refused with it.

BO-66 — Mobile app versionsCopy Anchor Link

Purpose. Control the mobile apps' version policy per app and platform, and maintenance mode (cahier §9, §13.4).

Who uses it. Super admin (with Imad at each release).

Entry points. Administration › Versions des applications.

Layout. One card per app (Application revendeur, Application délégué) × platform (Android; iOS when published).

The reseller web is not versioned; it is updated on deploy.

Data. admin.appVersions.crud. The apps read appConfig.get.

Actions.

• Raising the minimum version asks: « Les appareils sous la version 1.3.0 devront mettre à jour l'application avant de l'utiliser. Continuer ? ». Re-authentication; audited UPDATE.
• Turning maintenance on asks for confirmation.

Rules. The minimum version can never exceed the version published on the store; the person saving confirms this in the dialog. Delegates with unsynced offline data are warned in the app before the forced update (SYN-04).

Real-time. None.

States. iOS cards are hidden until iOS is enabled (HOCO's decision).

Acceptance criteria.

• With minimum version 1.3.0, an app at 1.2.9 gets 426 and the forced-update screen.
• Maintenance mode on the delegate app does not affect the reseller app.

BO-67 — Data importsCopy Anchor Link

Purpose. Run the initial imports of resellers, user accounts and stock (cahier §13.2 « Import initial des produits, revendeurs et comptes utilisateurs »). Products import through BO-32.

Who uses it. Super admin (go-live, LCH-01).

Entry points. Administration › Imports de données.

Layout.

• History table: Type, Fichier, Lancé par, Date, Statut (JobStatus), Lignes (created / updated / errors), Rapport.
  • Assumption — the list operation is missing (see contract notes).
• « Nouvel import » reuses the four steps of BO-32 (template, file, dry run, apply) with the type's columns:

Data. admin.imports.create (type, dryRun), admin.imports.get, files.createUpload.

Actions. As in BO-32: a dry-run report, then « Importer » with the confirmation of counts. One IMPORT audit entry per apply.

Rules. Applying is idempotent (same file, no duplicates). Nothing is written by the dry run.

Real-time. None. Progress comes from polling the job.

States. As in BO-32.

Acceptance criteria.

• A reseller file with a missing type_client is reported per row and cannot be applied for those rows.
• Re-applying the same reseller file creates no duplicate.
• A stock import creates one ADJUSTMENT per changed variant with the reason « Import initial ».

BO-68 — My profile & sessionsCopy Anchor Link

Purpose. Let each staff user manage their profile, password and sessions, and see their roles.

Who uses it. Every staff user.

Entry points. User menu › « Mon profil et sessions ».

Layout.

Data. me.get, me.update, auth.password.change, auth.sessions.list, auth.sessions.revoke.

Actions.

• Change the password: other sessions are revoked, with the toast « Mot de passe modifié. Vos autres sessions ont été fermées. ». Audited.
• Revoke a session: confirmation, audited.

Rules. Email and phone changes go through an administrator (BO-61). A phone change would need an OTP flow, which is not offered for staff in V1.

Real-time. None.

States. A wrong current password shows an inline error.

Acceptance criteria.

• After a password change, a session open on another computer is signed out.
• Revoking a session signs out that device at its next request.

BO-70 — Support regions & WhatsApp numbersCopy Anchor Link

Purpose. Group the wilayas into support regions, each with its WhatsApp support number and opening hours (§1b.8).

The fixed WhatsApp button of the reseller app and web opens the number of the user's region:

1. the region of the wilaya declared in their account, when signed in;
2. otherwise the region of the device location (nearest commune centroid → wilaya → region);
3. otherwise a wilaya picker, or the default number.

Who uses it. Super admin, with the commercial team.

Entry points. Administration › Régions support et WhatsApp (badge = wilayas without a region).

Layout.

• Table: Région, Numéro WhatsApp (national display with a wa.me test link), Horaires summary (« dim.–jeu. 08:30–17:00 »), Wilayas (count + names), Par défaut, Actif, Revendeurs couverts.
• Wilaya map: wilayas coloured by region. Unassigned wilayas are hatched, and a click assigns one to the selected region.
• Drawer:

• « Tester » panel: choose a wilaya, or enter coordinates. It shows the number, link and hours that support.whatsapp returns for that input.

Data. admin.supportRegions.crud (SupportRegion, SupportRegionWilaya), reference.wilayas.

Actions.

• Create and edit, audited CREATE / UPDATE.
• Moving a wilaya from one region to another asks « Déplacer Oran de Ouest vers Centre ? Les revendeurs d'Oran contacteront le numéro de Centre. »
• Deleting a region reassigns its wilayas to the default region after confirmation.

Rules.

• Each wilaya belongs to at most one region. Wilayas without a region use the default region.
• Changes apply to the next support.whatsapp call. The apps cache the resolved number for at most 24 h. Assumption — to align with the apps.
• Numbers are shown to guests too: the WhatsApp button works in guest mode (AUTH-10).

Real-time. None.

States. First use: one default region with HOCO's main number, covering every wilaya. Assumption — the number is to be provided by HOCO.

Acceptance criteria.

• A signed-in reseller whose declared wilaya is in Ouest opens the Ouest WhatsApp number from the app.
• A guest located in a wilaya without a region gets the default region's number.
• A wilaya cannot be assigned to two regions.
• The « Tester » panel returns the same number as the reseller app for the same wilaya.