Update released
Being able to trust what the screen tells you. And knowing that a member won't be locked out of your organization by accident. This update shores up the groundwork beneath everyday actions.
⚠️ When something fails, it now looks like a failure
Until now, when an action was rejected on the server, some screens displayed nothing at all and behaved exactly as they would have on success. A change that had never actually been applied appeared to be complete.
Two cases stood out. When resetting a password, the screen said “Your password has been reset” and moved on to the login page even when the password had not actually changed. When editing a product backlog item with an expired subscription, the item appeared to save even though nothing had been stored.
With this update, these screens now show the reason the action failed. What you see on screen no longer disagrees with what actually happened.
The same applies to creating and revoking API keys. Previously a failure produced no message at all, making the dialog look unresponsive; now the reason is shown (a failed creation appears inside the dialog, a failed revocation as a notification after the dialog closes). We also cleaned up a case where a failed password reset displayed the same message twice instead of once.
💬 What went wrong, and what to do next, in your language
The logic that classified error types had fallen out of step with the internal format, so in practice no classification took place and the raw English message returned by the server was displayed as-is. Reaching a plan limit, having authentication expire, and failing to connect all skipped the guidance that had been prepared for them.
With this update, an explanation matched to the type of error, along with the action to take next, now appears in the language you use.
- When you reach a plan or feature limit — instead of an English message, you see guidance on upgrading.
- When authentication expires — you are pointed toward logging in again.
- When a connection fails — you see a message prompting you to retry.
- When a password reset or invitation link cannot be used — you see an explanation of the situation, whether the link is invalid, expired, or has hit the maximum number of attempts. The suggested next step differs by route: password resets point you to requesting a new email, and invitations point you to asking an administrator to send the invitation again.
Actions that previously fell back to generic wording such as “Failed to save” or to an English message now show guidance suited to the situation as well. This covers deleting an organization account, editing product goals and sprint goals, product backlog item details and AI-assisted generation, AI analysis of retrospectives, creating tasks and working with task details, creating scrum teams, editing sprints, and actions on user details.
All of the above are display-side fixes. The errors the server returns and the processing behind them are unchanged.
🔐 Changing a member’s account status is now limited to organization owners
On user details in the admin panel, the controls for changing account status were shown regardless of whether you were an owner, which meant any member could suspend or reactivate a colleague from the screen. Even with no ill intent, a mis-click could lock a colleague out, and nobody noticed until that member could no longer log in.
With this update, only an organization owner can change another member’s account status (suspend and reactivate). For members who are not owners, and when you open your own details, the current status appears as a label only, with no path to change it. Likewise, only owners can change another member’s name or picture. Changing your own name and picture remains available to every member. Note that your own account status cannot be changed, even by an owner.
Viewing the member list and member details, sending invitations, and creating users all remain available to every member, as before. What has been restricted is not reaching the screen, but individual actions within it.
We also stopped accepting actions that would leave the organization with nobody able to manage it. This restriction keeps at least one owner who can sign in at all times: if you are the only owner who can sign in, actions that would break that state are unavailable, and the reason appears on screen. Suspended owners cannot sign in, so they are not counted toward that total — which means removing owner permission from a suspended owner, or removing them from the organization, works just as it did before. The confusing case is when a co-owner is suspended and the screen appears to show two owners. Even then you are the only owner who can sign in, so you cannot remove your own owner permission.
We also fixed the following issues:
- Owner permission could not be toggled on user details.
- Saving user information could appear to succeed when it had actually failed. Cases such as reactivating a suspended member while at your plan’s maximum number of users now correctly show on screen that the change could not be saved.
- When a change to owner permission or a member removal failed, a generic message naming only the type of action was displayed. The reason — such as no other owner being able to log in — is now shown.
- Changes to owner permission, and the name an invited member registers when accepting an invitation, were not reflected on the screens of other members with the user list open.
Note that suspension applies per organization. If you suspend a member who belongs to several organizations, they are locked out of that organization but can still sign in to the others. Members remain unable to act on users in other organizations, exactly as before.
📮 Contact us
If you have any questions or feedback, please don’t hesitate to reach out.
- ✉️ Email: info@on-your-side.llc