List / Edit / Delete just owner objects - Sonata Admin

[Cassiano Tartari]

H

i everybody!

I'm trying to configure my sonata admin bundle with ACL to the root user create users

,

and then these users create your own objects in the system, but I want is that these root's users can only edit/list/delete objects created by them.

So for each user created by root they will see a personal sonata admin system with just his own objects

,

but for the root will see everything.

Can somebody give a way to do this? It is a hard way learn symfony with sonata bundles by myself

Thanks

[Gabriel Richards]

I'm currently struggling with almost the same thing.

I've managed to get ACL working with Sonata Admin... but it seems the default implementation is basically Role / Class based security. You can set one or more Roles for each ACL managed entity in your system, but that gives the user access to at least View ALL objects of that entity type.

In my case, I do not want to give even Guest level access to any entity. Instead, I want to give Master access to one specific Object of an Entity.

So, I've managed to do that with some custom postPersist logic... however, what I'm finding, is that since the user does not have LIST permission for the entire class, he cannot see even the one object he is Master of!

I would expect that if the user has any permission level for at least one of an object of an entity type, then he should be able to access List view, but only see his permitted objects.

Hope I'm being clear. 

Assuming I am, can anyone point me in the direction of the "expected solution" for this type of issue, if any? If there isn't a built-in Symfony / Sonata solution for this... what is the best path for customization? I'm thinking:

1) Override the isGranted method in the admin classes to redefine the meaning of granting LIST permission.

2) Override the createQuery method in the admin to return the permitted list of objects.

Is that what I've got to do or is there some other purely ACL configuration related solution?

TY,

G

[Cassiano Tartari]

On Sun, Mar 31, 2013 at 7:11 PM, Gabriel Richards <gabriel.le...@gmail.com> wrote:

createQuery

I made this overriding the createQuery method...

Cassiano Valle Tartari
MSc. Computer Engineer

Tel: +55.48.84474818
Email: fal...@cassianotartari.eng.br
Site: http://www.cassianotartari.eng.br

[marco figus]

Hi, could you please port changes you made in  public function createQuery($context = 'list') overriding?

Thanks in advance
BR

[Gabriel Richards]

Hi Marco.

It's like this:

public function createQuery($context = 'list')

{

    $query = parent::createQuery($context);

    if (whatever my conditions are) {

        $query->andWhere('o.someProperty = :someValue')

            ->setParameter('someValue', someValue);

    }

    return $query;

}

So it's up to you to define the logic and constrain the query to return only the objects you want for the list.

Gabe

--
You received this message because you are subscribed to a topic in the Google Groups "sonata-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonata-users/GDZLFKx_CEQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonata-users...@googlegroups.com.
To post to this group, send email to sonata...@googlegroups.com.
Visit this group at http://groups.google.com/group/sonata-users.
For more options, visit https://groups.google.com/groups/opt_out.

--

400 S. Crenshaw Blvd. Suite 100, Torrance, CA 90503

tel: (310) 400-0800 | Email: gric...@endertech.com | www.endertech.com

Connect with Us!     Twitter  |  LinkedIn

[marco figus]

Hi Gabriel, I understand what you mean and it is exactly where I'm stucking now, that's because, my real question is... what should I look for in my object (entity) parameters to be compared with running authenticated user?

I'm using ACLs and I see that if I access as super_admin I can see wich users are objects "OWNERS", but.. where this information come from in db (entities mapped)?
When a make a query for an object list... wich attribute should I check in the object to be compared with logged user's information?
Consider that obviously I can access logged used details using the security.context....
and finally I just need to know what to look for in stored object.
Hope that now it is more clear.

Thanks again in advance
BR
Marco

[Gabriel Richards]

Wouldn't that be contingent upon your model's setup?

For instance, I might have a "Job" that has an "OWNER" of one user (the person who created the Job), but the Job has also a "Manager", which is set by a property like $job->manager and assigned by the OWNER.

I might ALSO want the manager to be able to edit the job, yet, he would not be in the ACL for that Job.

So, in this case it might look like:

public function createQuery($context = 'list')

{

    $query = parent::createQuery($context);

    if ($this->isGranted('ROLE_MANAGER') {

        $query->andWhere('o.manager = :manager')

            ->setParameter('manager', $this->getUser());

    }

    return $query;

}

You might override isGranted() or use Voters to give the Manager edit privilege:

G

[marco figus]

Hi Gabriel,

I finally solved adding a "ownerusername" property to all my entities, this property is setted up when comeone using the Admin creates a new entity with the username of the logged in user (overriding prePersist in all entitiesAdmin):

    public function prePersist($object) {
        $container = $this->getConfigurationPool()->getContainer();
        $username = $container->get('security.context')->getToken()->getUser()->getUsername();
        $object->setOwnerusername($username);
    }

object is obviously the entity that I want LIST view control.

And finally I can controll the list creation checking overriding always in Admin:

    public function createQuery($context = 'list')
    {
        $query = parent::createQuery($context);

        // this is the queryproxy, you can call anything you could call on the doctrine orm QueryBuilder
        $query->andWhere( $query->expr()->eq($query->getRootAlias().'.ownerusername',':username') );
        $container = $this->getConfigurationPool()->getContainer();
        $username = $container->get('security.context')->getToken()->getUser()->getUsername();
        $query->setParameter('username', $username); // eg get fromsecurity context
        return $query;
    }

Everything seems ok now.

I think that I expected too much from ACL, because actually they works on existing objects controlling EDIT, VIEW, DELET.... but not LIST.

Thanks again

BR
Marco