When having a bunch of notifications and the user is scrolling down the
content it is helpful to keep the header visible so the user can easily
mark all of them as read if they want to.
After dogfooding the notifications we noticed that admins will probably
have a larger number of unread notifications everyday so with that in
mind we decided to increase the "truncate" rate from 9+ to 99+.
**Preview:**
<img width="479" alt="Screenshot 2025-03-18 at 10 38 25"
src="https://github.com/user-attachments/assets/2e4cb48e-3606-478c-a68d-13465789330b"
/>
[Figma
file](https://www.figma.com/design/5kRpzK8Qr1k38nNz7H0HSh/Inbox-notifications?node-id=1-2726&t=PUsQwLrwyzXUxhf1-0)
**This PR adds:**
- Notification widget in the navbar
- Show notifications
- Option to mark each notification as read
- Update notifications in realtime
**What is next?**
- Option to mark all the notifications as read at once
- Option to load previous notifications - Right now, it only shows the
latest 25 notifications
- Having custom icons for each type of notification
**And about tests?**
The notification widget components are well covered by the current
stories, but we definitely want to have e2e tests for it. However, in my
recent projects, I found more useful to ship the UI features first, get
feedback, change whatever needs to be changed, and then, add the e2e
tests to avoid major rework.
Related to https://github.com/coder/internal/issues/336
* Improves separation of concerns between `runDockerInspect` and
`convertDockerInspect`: `runDockerInspect` now just runs the command and
returns the output, while `convertDockerInspect` now does all of the
conversion and parsing logic.
* Improves testing of `convertDockerInspect` using real test fixtures.
* Fixes issue where the container port is returned instead of the host
port.
* Updates UI to link to correct host port. Container port is still
displayed in the button text, but the HostIP:HostPort is shown in a
popover.
* Adds stories for workspace agent UI
This PR is part of the inbox notifications topic, and rely on previous
PRs merged - it adds :
- Endpoints to :
- WS : watch new inbox notifications
- REST : list inbox notifications
- REST : update the read status of a notification
Also, this PR acts as a follow-up PR from previous work and :
- fix DB query issues
- fix DBMem logic to match DB
- Add provisioner jobs back, but as a sub page of the organization
settings
- Add missing storybook tests to the components
Related to https://github.com/coder/coder/issues/15192.
A few audit logs can have the user as null which means the user is not
authenticated when executing the action. To make it more explicit we
named than as "Unauthenticated user" in the log description instead of
"undefined user".
Using negative permissions, this role prevents a user's ability to
create & delete a workspace within a given organization.
Workspaces are uniquely owned by an org and a user, so the org has to
supercede the user permission with a negative permission.
# Use case
Organizations must be able to restrict a member's ability to create a
workspace. This permission is implicitly granted (see
https://github.com/coder/coder/issues/16546#issuecomment-2655437860).
To revoke this permission, the solution chosen was to use negative
permissions in a built in role called `WorkspaceCreationBan`.
# Rational
Using negative permissions is new territory, and not ideal. However,
workspaces are in a unique position.
Workspaces have 2 owners. The organization and the user. To prevent
users from creating a workspace in another organization, an [implied
negative
permission](https://github.com/coder/coder/blob/36d9f5ddb3d98029fee07d004709e1e51022e979/coderd/rbac/policy.rego#L172-L192)
is used. So the truth table looks like: _how to read this table
[here](https://github.com/coder/coder/blob/36d9f5ddb3d98029fee07d004709e1e51022e979/coderd/rbac/README.md#roles)_
| Role (example) | Site | Org | User | Result |
|-----------------|------|------|------|--------|
| non-org-member | \_ | N | YN\_ | N |
| user | \_ | \_ | Y | Y |
| WorkspaceBan | \_ | N | Y | Y |
| unauthenticated | \_ | \_ | \_ | N |
This new role, `WorkspaceCreationBan` is the same truth table condition
as if the user was not a member of the organization (when doing a
workspace create/delete). So this behavior **is not entirely new**.
<details>
<summary>How to do it without a negative permission</summary>
The alternate approach would be to remove the implied permission, and
grant it via and organization role. However this would add new behavior
that an organizational role has the ability to grant a user permissions
on their own resources?
It does not make sense for an org role to prevent user from changing
their profile information for example. So the only option is to create a
new truth table column for resources that are owned by both an
organization and a user.
| Role (example) | Site | Org |User+Org| User | Result |
|-----------------|------|------|--------|------|--------|
| non-org-member | \_ | N | \_ | \_ | N |
| user | \_ | \_ | \_ | \_ | N |
| WorkspaceAllow | \_ | \_ | Y | \_ | Y |
| unauthenticated | \_ | \_ | \_ | \_ | N |
Now a user has no opinion on if they can create a workspace, which feels
a little wrong. A user should have the authority over what is theres.
There is fundamental _philosophical_ question of "Who does a workspace
belong to?". The user has some set of autonomy, yet it is the
organization that controls it's existence. A head scratcher 🤔
</details>
## Will we need more negative built in roles?
There are few resources that have shared ownership. Only
`ResourceOrganizationMember` and `ResourceGroupMember`. Since negative
permissions is intended to revoke access to a shared resource, then
**no.** **This is the only one we need**.
Classic resources like `ResourceTemplate` are entirely controlled by the
Organization permissions. And resources entirely in the user control
(like user profile) are only controlled by `User` permissions.
![Uploading Screenshot 2025-02-26 at 22.26.52.png…]()
---------
Co-authored-by: Jaayden Halko <jaayden.halko@gmail.com>
Co-authored-by: ケイラ <mckayla@hey.com>
resolvescoder/internal#392
In situations where a user accesses the org members without any
permissions beyond that of a normal member, they will only be able to
see themselves in the list of members.
This PR shows a warning to users who arrive at the members page in this
situation.
<img width="1145" alt="Screenshot 2025-02-26 at 18 36 59"
src="https://github.com/user-attachments/assets/16ad6ce1-2aa9-4719-bdae-914aff0fcd52"
/>
Bruno Quaresma