Permissions for related records

31 views
Skip to first unread message

Paul Cipollone

unread,
Feb 10, 2021, 11:13:16 AMFeb 10
to Xataface
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

unread,
Feb 10, 2021, 11:31:04 AMFeb 10
to xata...@googlegroups.com

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

unread,
Feb 10, 2021, 1:06:39 PMFeb 10
to Xataface
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.

Steve Hannah

unread,
Feb 10, 2021, 1:12:21 PMFeb 10
to xata...@googlegroups.com
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

unread,
Feb 12, 2021, 9:23:18 AMFeb 12
to Xataface
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?

Steve Hannah

unread,
Feb 12, 2021, 10:07:03 AMFeb 12
to xata...@googlegroups.com
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

unread,
Feb 13, 2021, 11:34:01 AMFeb 13
to Xataface
I'm obviously doing something wrong.

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

...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.

Paul Cipollone

unread,
Feb 14, 2021, 11:40:24 AMFeb 14
to Xataface
...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

unread,
Feb 18, 2021, 12:47:16 PMFeb 18
to Xataface

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

bigg...@gmail.com

unread,
Apr 7, 2021, 1:31:49 PMApr 7
to Xataface
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

unread,
Apr 7, 2021, 2:01:25 PMApr 7
to Xataface
and that line was...

bigg...@gmail.com

unread,
Apr 9, 2021, 7:15:38 PMApr 9
to Xataface
...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

unread,
Apr 9, 2021, 7:17:49 PMApr 9
to Xataface
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:
Reply all
Reply to author
Forward
0 new messages