Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qa: Modelling hierarchies #237

Merged
merged 4 commits into from
Dec 16, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
text updates
  • Loading branch information
rideam committed Dec 15, 2024
commit 35398df6d555b85627d655af0f5fa1ace7abe6c7
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@
Note that entities and applications cannot be related, even if they represent the same physical company. Only users can have entity grants to entities.

{/* <TypesDiagram /> */}
![mermaid1](/img/docs/extend/examples/modeling-hierarchy/mermaid1.webp)
![Types diagram](/img/docs/extend/examples/modeling-hierarchy/mermaid1.webp)

There are only two permission blocks in this diagram to avoid clutter. This isn't quite accurate, as in FusionAuth each entity grant would point to a separate permission — objects don't share permissions.

Expand All @@ -93,7 +93,7 @@
Below is a diagram of the company structure to model.

{/* <CompanyDiagram /> */}
![mermaid2](/img/docs/extend/examples/modeling-hierarchy/mermaid2.webp)
![Company diagram](/img/docs/extend/examples/modeling-hierarchy/mermaid2.webp)

<Aside type="note">
You can probably see some challenges already:
Expand All @@ -110,7 +110,7 @@
- **2) Entities and grants**: Create entity types Company and Department with permissions Read, Write, and IsMember. Read and write are used to show permissions, but IsMember is used to show hierarchy. Create an entity called Change Bank of type Company and entity of Department called Operations. Create an entity grant for Operations to Change Bank with IsMember set to true to show that this Operations entity belongs to the Change Bank entity. Note that it will not be possible to tell departments called Operations in different companies apart by their name alone. You will need to examine each department's entity grant to see which company it belongs to. Create an entity grant for user Alice to entity Change Bank with no permissions, and an entity grant for Alice to Operations with permissions Read and Write. Below is a diagram of this example, which is similar to the earlier types diagram, but includes a department hierarchy now. Permissions are shown in separate blocks now too.

{/* <HierarchyDiagram /> */}
![mermaid3](/img/docs/extend/examples/modeling-hierarchy/mermaid3.webp)
![Hierarchy diagram](/img/docs/extend/examples/modeling-hierarchy/mermaid3.webp)

For simplicity's sake this diagram does not include Change Corp entity of entity type Corporation. There are two blocks: one for Change Insurance and one for Change Bank. Ignore the Change Insurance block and concentrate on Change Bank to see how Alice is connected to her department, which is connected to the company. This diagram also shows a document attached to the Operations department. The document itself has needs read and write permissions, for when you want to enable individual access, and is linked to the Operations department via an entity grant with the IsMember permission, in the same way departments are linked to companies.
- **3) User JSON data**: Store every user's company and department as properties in their JSON `user.data` field. This has to be done through the FusionAuth API, and cannot be maintained in the FusionAuth web interface. You will need to write your own UI app for HR staff to work with FusionAuth. With this approach you don't need to use applications, roles, or groups. Below is example JSON data for Alice:
Expand Down Expand Up @@ -297,7 +297,7 @@
}
```

Note that the FusionAuth API key is hardcoded into this file and passed to Axios. In reality, you should never commit your key to Git, but keep it in a `.env` file. The rest of the code is simple: it calls the FusionAuth API for each type and stores the result returned. Read more about the API for [users](/docs/apis/users), [entities](/docs/apis/entities/entities), and [grants](/docs/apis/entities/grants).

Check failure on line 300 in astro/src/content/docs/extend/examples/modeling-hierarchies.mdx

View workflow job for this annotation

GitHub Actions / runner / vale

[vale] reported by reviewdog 🐶 [Vale.Terms] Use 'axios' instead of 'Axios'. Raw Output: {"message": "[Vale.Terms] Use 'axios' instead of 'Axios'.", "location": {"path": "astro/src/content/docs/extend/examples/modeling-hierarchies.mdx", "range": {"start": {"line": 300, "column": 76}}}, "severity": "ERROR"}

Continue the function above by calculating the permissions for the user for every document, and end the script by calling the function.

Expand Down
Loading