RowLevelSecurity Policy Table access could be handled more cleverly

[RogerTangos]

Access to the RowLevelSecurity policy table (defined in settings.py) is managed by the RowLevelSecurity table. For ever user, signals.py and rlsmanager.py write three entries the RLS Policy Table. These allow them to select, update, and insert rows where they are the grantor.

Migration 0017_security_policy_table.py and create_security_policy_table.py handle this for existing users.

A much more elegant way to implement this is to delete the add_existing_users_to_security_policy_table method in create_security_policy_table.py, remove add_user_to_policy_table in signals.py the method in signals.py, and had the migration insert these three lines into the RLS Policy Table.

insert into dh_public.policy (policy, policy_type, grantee, repo_base, repo, table_name) 
    values('grantor=current_user', 'select', 'all', 'postgres', 'policy', 'dh_public', 'dh_public')
​
insert into dh_public.policy (policy, policy_type, grantee, repo_base, repo, table_name) 
    values('grantor=current_user', 'insert', 'all', 'postgres', 'policy', 'dh_public', 'dh_public')
​
insert into dh_public.policy (policy, policy_type, grantee, repo_base, repo, table_name) 
    values('grantor=current_user', 'update', 'all', 'postgres', 'policy', 'dh_public', 'dh_public')

This is a good and small ticket for someone wanting to learn a bit about Django migrations operations and Row Level Security.