Introduction to Capability/Role/User system principle

Each instance of fireback (each configuration, or project lets say) can have it's own list of capabilities defined. Capabilities are a list, almost a an array of strings, that represent actions possible within entire system.

For example, each instance comes at least with owner capability, which is assigned by default to a user when signs up for his own workspace, or creates a new workspace.

This is more of a contract within software developers, like backend - mobile or backend - frontend to have a way to limit the user access on the UI.

On the backend side, capabilities need to be checked, to make sure if a user is allowed to really do an action.

In FireBack, each backend instance (per database) has unique capabilities among all workspaces, and clients. It means if you start your backend server at 4500 as an instance, and many users join, create their workspaces, all of them will see the same list of capabilities

On the other hand, Roles are workspace specifc, each user can defined their own roles, and assigning capabilities to that role. Each user can have zero or many roles, managed by owner or someone who has the role management access

Your case

Let's assume you are building your own Todo software. You need to consider what actions each user can do on the system, a quick thought:

• They can create todo, (CREATE_TODO)
• They can read todo someone else has been created, (READ_TODO)
• They can delete todos (DELETE_TODO)

As you see, you need to add these capabilities to FireBack in order to extend your backend and front-end and later, in the UI or your backend, you would check if someone has the possbility of deleting todos.

In many systems for simplicity delete and create are combined and it's called write instead. Some developers find it hard to make the system to differentiate between these states, later updates and so on.