I see from the documentation it is possible to add a permission to
auth_permission with a blank table name. The application I am working
on has a notion of symbolic names for actions that can occur in the
application which in a prior version was assigned to groups (roles)
and then users were assigned to groups. There is no crud associated
with a table.
If I turn off the
table.table_name.requires = IS_IN_SET(self.db.tables)
validator then I can get a form to put in a blank table name. If I
also set the record_id to 0 during the insert then the decorator
@auth.requires_permission('symbolic_name')
works without specifying a table name or record_id because of default
parameters.
If I put in a table name during the insert then the table name must be
supplied on the auth.requires_permission decorator.
The manual has examples like this
@auth.requires_permission('add', 'number')
def add(a, b):
return a + b
where I am reasonably sure 'number' isn't a table.
Question:
Am I using this incorrectly? The reason I want the symbolic names for
capabilities in the application to be realised as permissions is I can
cluster them on a group but reconfigure them for a different situation
to a different mix of groups and then knowing that mapping give the
users membership in the proper group(s) so they have access to the
application functionality intended for them. Then I can use the nice
decorator capability on the controller functions.
Possible solutions
I could just use an existing table or create a dummy table so I can
slip this by the validators while in forms. But then the decorator has
the extra table name parameter which isn't really used for anything.
I could put my own logic in the forms for the permission creation or
stick the initial setup in a script and fly under the validators but
invariably someone will want a form to change things after the
programmer is gone.
I could add my own table for symbolic capabilities with a relation to
auth_group and reproduce the decorator functionality.
Thanks
Ron
