Knowledge Base

Settings

Account, team, permissions, integrations and system settings.

27 pages

All topics in this area

What's new?

  • Deleting staff now requires the matching permission (#3411)

    The delete button in staff settings used to be visible to anyone who could open the page, even without the "delete staff" permission - a click used to end in a server rejection only. The button now only appears for roles that hold that permission.

    Open the Knowledge Base →

  • The role editor dialog now closes with Escape and is announced as a dialog (#3419)

  • Blue text in dark mode is now properly legible (#2945)

    in dark mode, blue pieces of text - ticket numbers, linked names, active tabs, markers in tables - used a blue that was too dark on the lighter surfaces, cards and table rows. Measured, it reached only 4.4:1 of contrast there; WCAG 2 AA asks 4.5:1 for normal text. On the very dark page background it was barely noticeable, on every raised surface it was - and that is where most of the text sits. Those places now use the lighter blue and reach at least 6.1:1. Hovering still brightens the colour visibly, so the difference between resting and touched is preserved. Icons, borders and the large figures on the KPI cards keep their blue: a different threshold applies to them, and they already meet it. Nothing changes in light mode.

    Open the Knowledge Base →

  • A custom role's rank is now saved

    When creating or editing a role under Settings → Staff & roles, the rank set with the slider used to be discarded - the role kept the internal default of 0 and therefore always sorted to the bottom of any rank-ordered list, regardless of what was chosen. Reopening the role also showed the default of 50 again, with no indication that the actual value had never been saved. The rank is now persisted and shown correctly the next time the role is opened, and the role list sorts custom roles into their real place among the system roles.

    Open the Knowledge Base →

  • Permission changes take effect again in every company

    Roles, permissions and account changes are carried across in the background into the store that sign-in reads permissions from. For a single company that transfer could come to a permanent halt - permissions there stayed at the state of the day it stopped: a revoked permission kept working, a newly granted one did not apply. The trigger was an account whose e-mail address was still held by a deleted account; the transfer now frees the address before it writes, and retries individual conflicts instead of stopping the whole company. If one account still cannot be carried across, only that account is affected: every other account, role and permission of the company keeps being transferred, and the outstanding account is reported by name. On top of that, each pass now gives up after ten minutes per company rather than waiting indefinitely. Nothing to do on your side - the transfer catches up on its own.

    Open the Knowledge Base →

View all release notes →