Limited Access affects searches

[APost]

I'm trying to limit some user's to seeing only specific records. I've created a privilege set that has Custom Records access with View privileges limited to record with values that match a field in their personal record.

It does just what I'd expect, but then they are unable to search. Any attempt yields "no records match this set of find requests" even if they simply copy a field value and paste it back into the find request.

Like what's up?

[Steven H. Blackwell]

The Boolean test is probably incorrect. The expected behavior is that a search for some value, e.g. where the field "City" is San Diego, returns only those records where the field "City" contains San Diego and that the user is othewise allowed to see. A record with "San Diego" that the user is not allowed to see is not included.

Steven

[APost]

Thanks for the input, I think I see whats going on now.

[APost]

Wait a minute, this works like a charm when I'm at the machine that's hosting the file, but doesn't work on a computer that's accessing a shared file???

When I try it from a "remote" computer any search yields "No Records match this set of Find Requests

Any ideas?

[Bob Freeman]

I am having a similar problem using the separation model for a complex ordering system hosted by v8.04 of FMSrvr Adv. I've limited access to line items (in its own file) by department_ID or lab_ID, and similar for purchase orders and purchase requisitions (together in their own file). However, from the UI, viewing a purchase order or purchase requisition lets me view these objects, but not their child line items from a portal on that layout. Searching the line items from its own layout in the UI permits me to browse records (either viewable or ), but when I search, I get the dreaded "No records found" message.

My UI files contains the global fields for department_ID and lab_ID, which should permit the match for the correct user. I'm assuming I don't have to embed these globals into each file; or do I?

Bob

[Steven H. Blackwell]

I can't tell from your description precisely what you're experiencing here. But as a general rule for Record Level Access the ability to view in the UI file is governed by the privileges set in the data file.

Presumably ALL files are on the Server?

Steven

[Bob Freeman]

Thanks, Steven for jumping on this. I'd hoped I'd get your attention for this matter.

All the files are hosted on the FMSA, and all the view/edit/create/delete are set in the data files.

What I'm discovering, and please correct me if I am wrong, is that for a given layout containing a portal (e.g. a purchase order with its line items), for a user to see the purchase order for his/her lab and its containing LIs, the view access privilege in the purchase order table (in one file) is set as

PO::Lab_ID = Interface::g_sec__Lab_ID

but for the line items table (in a separate file), the view access privilege must also encompass *any parent portal*. That is, the privilege must be set as

Line_item::Lab_ID = Interface::g_sec__Lab_ID or PO::Lab_ID = Interface::g_sec__Lab_ID

and a table occurrence for the purchase order table must be made in the line items data file.

This 'looking back from the other side of the portal window' phenomenon is nothing that I've seen documented anywhere, even on Filemaker's web site (aside, I must admit that I haven't bought your book *yet*). And as I've been developing in Filemaker for about 10 yrs (or more!), this threw me for a curve.

If I had permission to view purchase orders and also permission to view line items, I would think that I should be able to view those line items via a portal on the purchase orders layout. Hmmm.

(I'd post the files, but they're about 35 MB in size)

Bob

[Steven H. Blackwell]

Put the global fields into the data files and see what happens. You can still set the globals from the UI file and view the data from there.

As for getting my attention, never fear. As the Moderator of this Forum, I read every post. And I try to answer all that I possibly can.

Steven

[Bob Freeman]

Thanks, Steven. I will give it a try this weekend.

-B