Skip to content

fix(plugin-id): replace hardcoded entity probes with list probes for …#22

Merged
fdaugan merged 1 commit into
feature/vuejsfrom
norman/fix-demo-banner-probes
May 19, 2026
Merged

fix(plugin-id): replace hardcoded entity probes with list probes for …#22
fdaugan merged 1 commit into
feature/vuejsfrom
norman/fix-demo-banner-probes

Conversation

@Terracosmos
Copy link
Copy Markdown
Collaborator

Fixes a bug where the "Mode démo" banner appeared incorrectly on the
/new pages (user, company, group) whenever a real IAM provider was
configured.

Cause

Each EditView did an API probe on a specific hardcoded entity to
detect if the API was available:

  • UserEditView.vue → rest/service/id/user/admin
  • CompanyEditView.vue → rest/service/id/company/Ligoj
  • GroupEditView.vue → rest/service/id/group/Engineering

These entities exist in the iam:empty fallback (which returns fake
data for any id), but don't exist in real LDAP backends. So once
plugin-iam-node + plugin-id-ldap were activated, the probe returned
code != 0 (entity not found), which set demoMode to true and
displayed the banner — even though the API was working fine.

Fix

Replace the entity probe with a list endpoint (rows=1, page=1) that
returns 200 with an empty data array when nothing matches, and only
sets code on real API errors:

  • rest/service/id/user?rows=1&page=1
  • rest/service/id/company?rows=1&page=1
  • rest/service/id/group?rows=1&page=1

The demoMode flag is now only triggered when the API is genuinely
unavailable, not when the previously-hardcoded fixture entity
happens to not exist.

Test

Validated visually with LDAP active (plugin-iam-node + plugin-id-ldap

  • 1000 bench users):
  • /id/user/new, /id/company/new, /id/group/new → no demo banner
  • /id/user/cli1, /id/company/department1, /id/group/ →
    no regression on edit pages
  • Lint OK, build OK

Per Fabrice's review in the 18 mai 13:30 meeting.

…demo-mode detection

The previous probes ('user/admin', 'company/Ligoj' and 'group/Engineering')
checked for specific entities that don't exist in real LDAP backends, causing
the "Mode demo" banner to appear incorrectly on /new pages whenever a real
IAM provider (plugin-iam-node + plugin-id-ldap) is configured.

Switch to list endpoints with rows=1 which return 200 with an empty data
array when nothing matches, and only set code on real API failures.

Per Fabrice's review in 18 mai 13:30 meeting.
@Terracosmos Terracosmos requested a review from fdaugan May 18, 2026 13:57
@sonarqubecloud
Copy link
Copy Markdown

@sonarqubecloud
Copy link
Copy Markdown

@Terracosmos
Copy link
Copy Markdown
Collaborator Author

Update : ce fix a expose 2 bugs en cascade qui sont maintenant traites
dans des PR separees (toutes atomiques) :

  • norman/fix-container-resource-post (backend C) : 405 sur POST /group
    et /company exposes par la fin de la banniere demo
  • norman/fix-scope-payload-id (D) : 400 sur scope en string au lieu
    d'Integer expose apres le fix C
  • norman/fix-scope-dropdown-filter (E) : bug Vuetify decouvert en
    testant D

Aucune n'est bloquante pour merger #22, mais elles ont du sens
mergees ensemble (sinon le frontend ne peut toujours pas creer
company/group de bout en bout).

PUT update sur containers reste un blocker separe (chantier F dans
mon recap) — 4 options proposees, j'attends ton arbitrage.

@fdaugan fdaugan merged commit 9ca9e64 into feature/vuejs May 19, 2026
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants