Permissions for related records

[Paul Cipollone]

Have run into something that I thought was simple, but am having a bear of a time getting it to actually work.

I have two tables, and without getting too deep into things, the relationship is pretty simple. A member will have an 

assigned sales rep, and that's working fine. Pull up a member? I see the sales rep...but, for the related record

I don't want ANYONE to be able to edit, add, or delete. Just read only, but whenever I click into that related-record

table, I am able to edit/delete/update/etc.

Added this to the parent table PHP with some success:

  function rel_SalesRep__permissions($record){
   // $record is a Dataface_Record object
         return array(
           'view related records' => 1,
           'add new related records' => 0,
           'add existing related records' => 0,
           'remove related records' => 0,
           'delete related records' => 0
   );
 }

And yet all those things remain. If I set the view to 0, the related record goes away, so I know that part is being

read, and based on the docs, that should work. Don't have any roles/permissions/logins defined at all...this is 

only read by very few people internally, and this behavior should be global.

Tried a permissions.ini, but it doesn't seem to have any effect at all....thoughts are welcome, please.

Thanks

[Steve Hannah]

The effective permissions for the record when editing it will be defined by the permissions on the related table.  If you deny the "edit" permission on that table, then they won't be able to edit records there.

--
You received this message because you are subscribed to the Google Groups "Xataface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xataface+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/98c36a21-f3b8-4cfe-a364-2f5ad8460441o%40googlegroups.com.

--

Steve Hannah

Web Lite Solutions Corp.

[Paul Cipollone]

Indeed...are you saying to make the database table itself read-only??  Because everything I've tried thus far with permissions.ini and what I put in

the parent-table's PHP leaves the edit/delete/copy buttons in place.

Editing the parent record is fine...I don't want anyone to be able to edit the related record for that one particular table.

To unsubscribe from this group and stop receiving emails from it, send an email to xata...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/98c36a21-f3b8-4cfe-a364-2f5ad8460441o%40googlegroups.com.

[Steve Hannah]

My default setup is to make everything no access by default.  (e.g. The ApplicationDelegate permissions are something like:

function getPermissions(Dataface_Record $record = null) {

    if (isAdmin()) return Dataface_PermissionsTool::ALL();
    return Dataface_PermissionsTool::NO_ACCESS();
}


Then in sub table that I want more specific permissions in, I would open it up with a more permissive getPermissions() method.

To unsubscribe from this group and stop receiving emails from it, send an email to xataface+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/b4ac0b07-440e-461e-b85f-53a764795039o%40googlegroups.com.

[Paul Cipollone]

Thought that might be the case. From the docs, it seems to say you can implement things site-wide, then give more fine-grained permissions

for one particular table, correct?

So if I wanted all my users to be able to read/write/edit/delete on all the tables except ONE, I would shove that function into the index.php in

the root, then put another, taking those permissions away for the table in question, right?

To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/b4ac0b07-440e-461e-b85f-53a764795039o%40googlegroups.com.

[Steve Hannah]

Yes.  You could "invert" those permissions.  Grant more permissions in the application delegate class and then implement a more restrictive getPermissions method in that one table.   I generally don't use this approach myself because I feel that the default should be "no access".   Xataface by default disallows access to tables beginning with xf_, df_, and dataface__. to prevent internal house-keeping tables made by Xataface from being accessed directly.  But I usually find that, as I go along, I'll at least create some auxiliary tables that I don't want to be public, and I'd prefer to err on the side of caution.

One "trick" I use when I have a lot of tables with the same permissions, is I'll create a PHP class that implements getPermissions(), and then use that as a base class for the delegate classes of those tables.

To unsubscribe from this group and stop receiving emails from it, send an email to xataface+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/4aa839ff-8309-40e9-bbc5-9199c37e6bado%40googlegroups.com.

[Paul Cipollone]

I'm obviously doing something wrong.

In my index.php, I have the delegate class listed in the "Getting Started with Permissions" link:

http://xataface.com/documentation/tutorial/getting_started/permissions

...because I want EVERYONE to log in. I have created the database, added users, modified the conf.ini file, and restarted everything. My application still

hops right up, except now I see a "Log In" link at the top, instead of getting prompted to log in. I can enter incorrect credentials, and it fails, so I know things

are getting read. Set a permissions.ini in my 'main' table as such:

[USER]

    view=1

    edit=1

[Admin]

    view=1

    edit=1

    delete=1

    

[RO]

view=1

edit=0

delete=0

No matter who I log in as, I get read/write/edit/delete, for every table.  I must be missing something bleedingly obvious, but I can't figure out what.

To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/4aa839ff-8309-40e9-bbc5-9199c37e6bado%40googlegroups.com.

[Paul Cipollone]

...and it WAS something bleedingly obvious, and was already documented on the "Getting Started with Permissions" page. I missed one line, but went back and re-read

it.  Helps when you follow the instructions. :)

[air drummer]

and it was...what? don't tease us;-)

[bigg...@gmail.com]

It was literally one line missing from the PHP instructions on the page mentioned. As stated, I missed one line....I added it as written on that page, and it worked.

[tom wible]

and that line was...

[bigg...@gmail.com]

...listed on that page, and I just don't remember any longer. And it doesn't matter, since (as stated) if those instructions/samples are FOLLOWED, things work. It would be like asking about a typo....as said I omitted a line from what is clearly written on that page.

Does it matter which one?? The solution to the problem stated here is, as stated..."Follow the instructions". 

[bigg...@gmail.com]

I went back and looked...this one

   $role = $user->val('Role');

Does that answer anything better than, again..."follow the instructions"?? 

On Wednesday, April 7, 2021 at 1:01:25 PM UTC-5 tew...@verizon.net wrote: