blob: 01f58fa0fd17cf77af5f7f63e7a65d3e283a5b73 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
# Authorization Logic in Policies
## Base Rules
### ApplicationPolicy
Policies inheriting from the `ApplicationPolicy` authorize _Undestructive_ _Permissions_ whiche are `index?` and
`show?`. And forbid _Destructive_ _Permissions_ which are `create?`, `destroy?` & `update`.
These _CRUD_ permissions are tied to to _Action_ permissions, `delete?`→ `destroy?`, `edit?` → `update? and `new?`→ `create?`.
These three _Action_ permissions are not supposed to be overriden in `ApplicationPolicy` subclasses.
### Common Policy Types
There are two common policy types.
#### Read Only Type Policy
This corresponds to inheriting from `ApplicationPolicy` without overriding one of the five aforementioned _CRUD_ permissions.
The following Policies are of this type.
- `Company`
- `GroupOfLine`
- `Line` + custom
- `Network`
- `StopArea`
#### Standard Type Policy
The standard type policy inherits from `ApplicationPolicy` does not override any _Undesructive_ _Pemission_ but overrides the _Destructive_ ones.
Normally, but not always they are overriden as follows
```ruby
def <destructive>?
!archived? && organisation_match? && user.has_permission('<resource in plural form>.<action>')
end
```
There are some variations (**TO BE CLARIFIED**) concerning `organisation_match?`.
The following Policies are of this type.
- `AccessLink`
- `AccessPoint`
- `Calendar` (*)
- `ConnectionLink`
- `JourneyPattern`
- `Referential` + custom
- `Route`
- `RoutingConstraintZone`
- `TimeTable` + custom
`Calendar` is a strange exception where no user permission is checked for the _destructive_ _permissions_.
|
