Workspaces

A workspace (tenant, in the code and in the API) is a whole NoteBugs inside the same NoteBugs: its own columns, projects, labels and cards. Nothing crosses the boundary, not even a link between two cards.

Why it exists

• To separate contexts that do not mix: a client's work, the internal team, personal projects.
• To give each context its own column set: a support board does not have the same stages as a product board.
• To be the unit of access: a person is a member of some workspaces and simply does not see the others.

How it works

1. 1A new workspace is born with the 5 default columns, created in the same transaction. There is no seed and no configuration step.
2. 2Card, project, label and column carry tenantId, and it is immutable: no edit schema accepts that field.
3. 3The epic is the exception: it inherits the project's workspace, which is why POST /api/epics does not ask for tenantId.
4. 4Whoever is a member of no workspace gets an empty board, not an error: it is a state of the account.

Things to watch for

• The last workspace is not deleted. The check happens inside the transaction, so two simultaneous requests do not both get through.
• Deleting takes everything along (cards, projects, epics, labels, comments and the files on the volume), which is why the route requires the phrase APAGAR TENANT in the body.
• A card's number (`#42`) is unique across the whole installation, not per workspace: it exists to cite the card in a commit, so two #42 in different workspaces cannot exist.
• Workspace order has its own route (/api/tenants/order) and takes a subset, like epics and columns.