Changes between Version 93 and Version 94 of BluePrintAuthorization

Timestamp:

07/04/10 13:41:41 (15 years ago)

Author:

Fran Boon

Comment:

Option B for Record-Level restrictions

BluePrintAuthorization

@@ -133 +133 @@
 
 === Record restriction ===
+==== Option A ====
  * Add 2 reusable {{{multiple=True}}} fields to each table which needs this: {{{reader_id}}} & {{{writer_id}}} combined as {{{permissions_id}}} for easy reuse within table definitions
   * Full backward compatibility since they default to None
@@ -324 +325 @@
 > records and check them afterwards.
 > Also, this model makes non-hardcoded roles extremly inefficient.
+
+==== Option B (Preferred?) ====
+Use the separate auth_permission table.
+
+Disadvantages:
+ * All Read permissions checks need to read 2 tables (hopefully via a Join rather than 2 DB calls)
+
+Advantages:
+ * More flexible since other methods can be added easily as-required (e.g. delete) 
+ * Module authors don't need to be aware of these restrictions (unless making use of them in other workflow areas)
+ * 1 secure place to manage all record-level restrictions
+ * No DB migrations/Code changes needed to implement restrictions
 === Field restriction ===
  * In model (for access by all controllers, such as sync):