I would just turn off
table.table_name.requires = IS_IN_SET(self.db.tables)
and use a dummy table name for the permission (without creating the
dummy table) and use a table name that cannot create conflict for
example something that include a special symbol like ":"
On Sep 10, 1:06 pm, ron_m <[email protected]> wrote:
> 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
