Repository navigation
Tags
Tags
fix(ui): keep the .dark class in sync with the theme variables The theme provider toggled the '.dark' class and set the CSS variables in two separate effects (deps [mode] vs [mode,color], plus a cleanup that stripped '.dark' on every re-run/unmount). They could drift apart: a dark app -- dark variables applied -- could end up WITHOUT the '.dark' class, so Tailwind 'dark:' variants fell back to their pale light-mode colours while every variable-driven surface stayed dark. Most visibly the database select-option badges rendered washed-out in the desktop build. Apply the class and the variables from one effect keyed on the same inputs so they can never diverge.
style(ui): theme native scrollbars to match the app Plain overflow areas (the sidebar, page content) used the browser's default scrollbar, whose track renders bright in dark mode and clashed with the rest of the dark UI. Style the native scrollbar with the theme's border/muted tokens (and scrollbar-color for Firefox). Radix ScrollArea viewports hide their own native scrollbar with a more specific selector, so their custom scrollbars are unaffected.
fix(desktop): sign-in window uses a fresh session and a plain-browser UA
The 'Se connecter avec Arribada' window reused a persistent session
('persist:oidc-login') and carried the Electron user agent. A stale or wrong
account (typically a personal Google account that is not an Arribada team
member) got stuck in it, so /sso/consent kept returning 403 and the flow
dead-ended; and the Electron user agent made the dashboard run its native
Google flow, which bounces through arribada:// -- a scheme this window does not
own -- and lands on a 404.
Give the window a non-persistent session so every sign-in starts from a clean
state, and strip the ArribadaWiki/Electron tokens from its user agent so the
dashboard runs the normal web login flow, which completes and is intercepted
here.
ci(desktop): keep the default branch's copy of the workflow in step This copy exists so GitHub shows the "Run workflow" button, which it only does for a workflow on the default branch. It had drifted: no Windows runner pin, and no check of which fork is being built. Building this branch produces Colanode, not the Arribada Wiki, so the run now stops at the first step and says to pick arribada/features. Until now it got as far as npm ci and died on a stale lock file, which said nothing about the real problem.
ci(desktop): keep the default branch's copy of the workflow in step This copy exists so GitHub shows the "Run workflow" button, which it only does for a workflow on the default branch. It had drifted: no Windows runner pin, and no check of which fork is being built. Building this branch produces Colanode, not the Arribada Wiki, so the run now stops at the first step and says to pick arribada/features. Until now it got as far as npm ci and died on a stale lock file, which said nothing about the real problem.
ci(desktop): keep the default branch's copy of the workflow in step This copy exists so GitHub shows the "Run workflow" button, which it only does for a workflow on the default branch. It had drifted: no Windows runner pin, and no check of which fork is being built. Building this branch produces Colanode, not the Arribada Wiki, so the run now stops at the first step and says to pick arribada/features. Until now it got as far as npm ci and died on a stale lock file, which said nothing about the real problem.
ci: list the Arribada Wiki desktop workflow so it can be run by hand GitHub offers "Run workflow" only for a workflow that exists on the default branch, and this fork's work lives on arribada/features. Without this file on main, the desktop build could only be started by pushing a tag. A manual run still builds the branch picked in the dialog, with that branch's own copy of the workflow.
ci: list the Arribada Wiki desktop workflow so it can be run by hand GitHub offers "Run workflow" only for a workflow that exists on the default branch, and this fork's work lives on arribada/features. Without this file on main, the desktop build could only be started by pushing a tag. A manual run still builds the branch picked in the dialog, with that branch's own copy of the workflow.