From b09994a4ee79f735f9b3f43535c6d138c4b68a56 Mon Sep 17 00:00:00 2001
From: Robert
Date: Wed, 5 Jul 2017 16:52:44 +0200
Subject: Refs:#3478@10h;

   Policy Refactoring and Policy Test Completion

   - All policies (and all permissions) under test.
   - Common patterns and potential problems identified...
   - ... and documented in DEVNOTES.md

   - some simply refactorings
---
 DEVNOTES.md | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 DEVNOTES.md

(limited to 'DEVNOTES.md')

diff --git a/DEVNOTES.md b/DEVNOTES.md
new file mode 100644
index 000000000..01f58fa0f
--- /dev/null
+++ b/DEVNOTES.md
@@ -0,0 +1,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_.
+
+
+
+
-- 
cgit v1.2.3


From 1b5b681603f629b901deabffc4c55f654bbcfe14 Mon Sep 17 00:00:00 2001
From: Robert
Date: Thu, 6 Jul 2017 11:40:03 +0200
Subject: Fixes: #3478@1.5h

  - Fixes remaining issues with LinePolicy, CalenderPolicy & RoutePolicy
  - Dead Code elimination
---
 DEVNOTES.md | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

(limited to 'DEVNOTES.md')

diff --git a/DEVNOTES.md b/DEVNOTES.md
index 01f58fa0f..2a3915ed2 100644
--- a/DEVNOTES.md
+++ b/DEVNOTES.md
@@ -33,7 +33,7 @@ The following Policies are of this type.
 
 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
+They are overriden as follows
 
 ```ruby
       def <destructive>?
@@ -41,21 +41,20 @@ Normally, but not always they are overriden as follows
       end
 ```
 
-There are some variations (**TO BE CLARIFIED**) concerning `organisation_match?`.
+**An exception** is `Referntial` which **cannot** check for `organisation_match?` for creation as there is no referential.
 
 The following Policies are of this type.
 
   - `AccessLink`
   - `AccessPoint`
-  - `Calendar` (*)
+  - `Calendar`
   - `ConnectionLink`
   - `JourneyPattern`
   - `Referential` + custom
-  - `Route`
+  - `Route` (used by `StopPoint` too)
   - `RoutingConstraintZone`
   - `TimeTable` + custom
 
-`Calendar` is a strange exception where no user permission is checked for the _destructive_ _permissions_.
 
 
 
-- 
cgit v1.2.3