Massimo,

    Thank you for your answer.  Before moving on, let me try to give a
quick example of a table:

db.define_table('resources',
  Field('name',label=T('name')),
  Field('company',db.company,label=T('category')),
  Field('department',db.department,label=T('department')),
  Field('long_description','text',default='',label=T('long
description')),
  ...
  )
     So for example a power user would have access to all the records
from his company, and a "normal" user, to any record from the
departments to which he may have access.

Now, I had discarded the decorator method, because, if I had correctly
understood it, I would need to add the permission of any single record
addition in that table to any group that should give access to that
new record. And in any case I would need to add an extra table for
storing access definitions of the sort of: group_id, table_name,
table_field_name, table_field_value (group_id, resources, department,
'IT') and then check them after every update or insert to the table.
So I figured that would be too much inserting into permissions.

Also, the nice thing about that would have been using the
accessible_query, but as it says there... well, cant be used with GAE.
And in CRUD the SELECT def, does not filter per accessible fields, so
the only real automated function that I would get would be the checks
for update and read single records.

    def accessible_query(self, name, table, user_id=None):
        """
        returns a query with all accessible records for user_id or
        the current logged in user
        this method does not work on GAE because uses JOIN and IN

        example::

           db(accessible_query('read', db.mytable)).select
(db.mytable.ALL)

        """
I do not know though If I have missunderstood or missed something
about this method.

The second option seems nicer, basically if I understand what you
mean, it is dinamically creating an extra clause in all queries.
Right?. Is that sintax correct? can I put subqueries as you mention?
return db(query)(subquery)(....).

I am in any case a bit afraid of GAE, I think I am ok, as these would
be all equalities and no inequalities are added on this part, (I think
GAE only lets you have one field with inequalities). But I am no
expert, and I am not sure I might screw it up by a bad table and auth
design.

As a side question. On a table such as the one shown up there, the
requires.IS_NOT_IN_DB() that would be needed, would need to check on 3
fields (that is, I dont want the same combination of Company/
Department/Name to happen how would that correctly be done? does that
translate correctly to GAE?

Thanks for your help,
Benigno.

On 10 ago, 08:52, mdipierro <mdipie...@cs.depaul.edu> wrote:
> The decorators
>
> @auth.requires_login()
> @auth.requires_membership('group')
> @auth.requires_permission('type','table'record_id')
>
> work on any function, work on gae and are efficient.
>
> You mail also want to build functions like
>
> def record(query):
>      if auth.has_permission(...):
>           return db(query).select(....)
>      else:
>           return db(query)(subquery)(....)
>
> Hope this helps.
>
> On Aug 9, 4:28 pm, Benigno <bca...@albendas.com> wrote:
>
> > Hello,
> >   I'd like to pose a question, that is probably quite basic, but I do
> > not see any way to do it right (by right meaning something that
> > doesn't take too many queries, processor, ram or looks really nasty on
> > the code).
>
> >   So, I would like to know what is the best way to set up an
> > authorisation process that filters data by different fields depending
> > on the authorisation of the given user. On its most basic form,
> > imagine that I am setting up a service app, that allows different
> > companies to sign in and pay for a number of users. Those users
> > grouped by department.
>
> >   I would like that they are able to set up the access rights for each
> > of those users, so that once they set a user with accesss to a certain
> > department (or several departments), anything he does is filtered for
> > those he has access only (this may span any number of tables in which
> > data may be company/department specific). Of course this for many
> > different companies.
>
> >   The second part of my question is: What would be the best way to set
> > it up so that it works nicelly in GAE?.
>
> > Thanks in advance,
> >        Benigno.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to