You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: adminforth/documentation/docs/tutorial/03-Customization/05-limitingAccess.md
+42-7Lines changed: 42 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ Before we start it is worth to mention that callbacks or scalars defined in `all
9
9
10
10
As you can see allowedAction callbacks are called in parallel in async manner. However it is important to keep them fast and not to make any slow operations in them, to keep UI responsive.
11
11
12
-
## Statically disable some action
12
+
## Statically disable some action on resource
13
13
14
14
You can use `options.allowedActions` on resource to limit access to the resource actions (list, show, create, edit, delete).
15
15
@@ -33,7 +33,43 @@ If you want to disable deletion of the resource records for all users:
33
33
}
34
34
```
35
35
36
-
## Disable some action based on logged in user record or role
36
+
## Disable full access to resource based on logged in user record or role
37
+
38
+
If you want to disable all actions to the resource for all users except users with role `superadmin`:
> ☝️ This will not hide link to the resource in the menu, you should separately use [menuItem.visible](/docs/tutorial/Customization/menuConfiguration/#visibility-of-menu-items) to hide it.
63
+
64
+
65
+
66
+
> ☝️ instead of reading role from user you can check permission using complex ACL/RBAC models with permissions stored in the database.
67
+
> However we recommend you to keep in mind that allowedActions callback is called on every request related to resource, so it should be fast.
68
+
> So try to minimize requests to database as much as possible.
69
+
70
+
71
+
72
+
## Disable only some action based on logged in user record or role
37
73
38
74
If you want to disable deletion of apartments for all users apart from users with role `superadmin`:
39
75
@@ -61,11 +97,7 @@ import type { AdminUser } from 'adminforth';
61
97
}
62
98
```
63
99
64
-
> ☝️ instead of reading role from user you can check permission using complex ACL/RBAC models with permissions stored in the database.
65
-
> However we recommend you to keep in mind that allowedActions callback is called on every request related to resource, so it should be fast.
66
-
> So try to minimize requests to database as much as possible.
67
-
68
-
## Reuse the same callback for multiple actions
100
+
### Reuse the same callback for multiple actions
69
101
70
102
Let's disable creating and editing of new users for all users apart from users with role `superadmin`, and at the same time disable deletion for all users:
Copy file name to clipboardExpand all lines: adminforth/documentation/docs/tutorial/03-Customization/10-menuConfiguration.md
+26Lines changed: 26 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,6 +53,32 @@ E.g. create group "Blog" with Items who link to resource "posts" and "categories
53
53
54
54
If it is rare Group you can make it `open: false` so it would not take extra space in menu, but admin users will be able to open it by clicking on the group name.
55
55
56
+
## Visibility of menu items
57
+
58
+
You might want to hide some menu items from the menu for some users.
59
+
60
+
To do it use `visible` field in the menu item configuration:
> 👆 Please note that this will just hide menu item for non `admin` users, but resource pages will still be available by direct
79
+
> URLs. To limit access, you should also use [allowedActions](/docs/tutorial/Customization/limitingAccess/#disable-full-access-to-resource-based-on-logged-in-user-record-or-role) field in the resource configuration in addition to this.
80
+
81
+
56
82
## Gap
57
83
58
84
You can put one or several gaps between menu items:
Copy file name to clipboardExpand all lines: adminforth/documentation/docs/tutorial/03-Customization/13-standardPagesTuning.md
+92-2Lines changed: 92 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -539,9 +539,9 @@ This way, when creating or editing a record you will be able to choose value for
539
539
540
540
When foreign resource column is not required, selector will have an 'Unset' option that will set field to `null`. You can change label for this option using `unsetLabel`, like so:
541
541
542
-
```typescript title="./resources/adminuser.ts"
542
+
```typescript title="./resources/apartments.ts"
543
543
exportdefault {
544
-
name: 'adminuser',
544
+
name: 'apartments',
545
545
columns: [
546
546
...
547
547
{
@@ -558,6 +558,96 @@ export default {
558
558
],
559
559
```
560
560
561
+
### Polymorphic foreign resources
562
+
563
+
Sometimes it is needed for one column to be a foreign key for multiple tables. For example, given the following schema:
564
+
565
+
```prisma title="./schema.prisma"
566
+
...
567
+
model apartments {
568
+
id String @id
569
+
created_at DateTime?
570
+
title String
571
+
square_meter Float?
572
+
price Decimal
573
+
number_of_rooms Int?
574
+
realtor_id String?
575
+
}
576
+
577
+
model houses {
578
+
id String @id
579
+
created_at DateTime?
580
+
title String
581
+
house_square_meter Float?
582
+
land_square_meter Float?
583
+
price Decimal
584
+
realtor_id String?
585
+
}
586
+
587
+
model sold_property {
588
+
id String @id
589
+
created_at DateTime?
590
+
title String
591
+
property_id String
592
+
realtor_id String?
593
+
}
594
+
595
+
```
596
+
597
+
Here, in `sold_property` table, column `property_id` can be a foreign key for both `apartments` and `houses` tables. If schema is set like this, the is no way to tell to what table exactly `property_id` links to. Also, if defined like usual, adminforth will link to only one of them. To make sure that `property_id` works as intended we need add one more column to `sold_property` and change the way foreign resource is defined in adminforth resource config.
598
+
599
+
```prisma title="./schema.prisma"
600
+
...
601
+
602
+
model sold_property {
603
+
id String @id
604
+
created_at DateTime?
605
+
title String
606
+
//diff-add
607
+
property_type String
608
+
property_id String
609
+
realtor_id String?
610
+
}
611
+
612
+
```
613
+
614
+
`property_type` column will be used to store what table id in `property_id` refers to. And in adminforth config for `sold_property` table, when describing `property_id` column, foreign resource field should be defined as follows:
When defined like this, adminforth will use value in `property_type` to figure out to what table does id in `property_id` refers to and properly link them. When creating or editing a record, adminforth will figure out to what table new `property_id` links to and fill `property_type` on its own using corresponding `whenValue`. Note, that `whenValue` does not have to be the same as `resourceId`, it can be any string as long as they do not repeat withing `polymorphicResources` array. Also, since `whenValue` is a string, column designated as `polymorphicOn` must also be string. Another thing to note is that, `polymorphicOn` column (`property_type` in our case) must not be editable by user, so it must include both `create` and `edit` as `false` in `showIn` value. Even though, `polymorphicOn` column is no editable, it can be beneficial to set is as an enumerator. This will have two benefits: first, columns value displayed in table and show page can be changed to a desired one and second, when filtering on this column, user will only able to choose values provided for him.
648
+
649
+
If `beforeDatasourceRequest` or `afterDatasourceResponse` hooks are set for polymorphic foreign resource, they will be called for each resource in `polymorphicResources` array.
0 commit comments