Code

#18488 closed New feature (invalid)

add granular permissions

Reported by: w_mike@… Owned by: nobody
Component: contrib.auth Version: master
Severity: Normal Keywords: security permissions
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

It would be nice to have a more detailed permission structure to represent each user only the tables, fields, functions, etc. that he is allowed to do anything to.

My basic thought was to have different credentials/security issues:

  • read
  • add
  • change
  • delete
  • execute

(- state transition -> for an implemented workflow -> other task)
plus each as a 'request' for and 'grant' to variation.

Then have the following targets:

  • table (Django model)
  • field (Django field)
  • dynamic field (a field that is ro and computed by other fields)
  • model function (each function defined in a model -> must be a new class: Django ModelFunction -> other task)
  • manager function (each function defined by a Manager, but granted per use in a Model)
  • state transition (for an implemented workflow -> other Task)

Lastly the Permissions themselves:
create a table with sensemaking credentials to each target:

  • table: read, add, change, delete, requestAdd, requestChange, requestDelete (same as request to grant)
  • field: read, change, request+grant change
  • dynamic field: read
  • model function: execute, request execute (+ store request to table), grant execute (and run execute from store)

-> same to manager function and to state changes

and that for each user, group, role (new object, where users and groups can be member in -> other task).

I found many projects that add row level permissions, what I don't need.

There should be more built-in support for granular permissions based on the table definitions itself including fields/columns and functions that can be executed to build a page dynamically based on these permissions.

Attachments (0)

Change History (1)

comment:1 Changed 22 months ago by jezdez

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

Please post feature requests to the mailing list first. More information about the feature request policy can be found in the docs: https://docs.djangoproject.com/en/1.4/internals/contributing/bugs-and-features/#requesting-features

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.