Changes between Version 93 and Version 94 of BluePrintAuthorization


Ignore:
Timestamp:
07/04/10 13:41:41 (11 years ago)
Author:
Fran Boon
Comment:

Option B for Record-Level restrictions

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintAuthorization

    v93 v94  
    133133
    134134=== Record restriction ===
     135==== Option A ====
    135136 * 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
    136137  * Full backward compatibility since they default to None
     
    324325> records and check them afterwards.
    325326> Also, this model makes non-hardcoded roles extremly inefficient.
     327
     328==== Option B (Preferred?) ====
     329Use the separate auth_permission table.
     330
     331Disadvantages:
     332 * All Read permissions checks need to read 2 tables (hopefully via a Join rather than 2 DB calls)
     333
     334Advantages:
     335 * More flexible since other methods can be added easily as-required (e.g. delete)
     336 * Module authors don't need to be aware of these restrictions (unless making use of them in other workflow areas)
     337 * 1 secure place to manage all record-level restrictions
     338 * No DB migrations/Code changes needed to implement restrictions
    326339=== Field restriction ===
    327340 * In model (for access by all controllers, such as sync):