Record Privileges vs Relations for multi user access to single table

[bme]

Maybe this is an obvious one, but I did browse and search a lot before posting.

What would be the best approach to let multiple users privately access the same table, while keeping intact as much native FM functionality (e.g. searching, sorting, exporting) as possible?

I was leaning towards a single table solution w record privileges based on log in accounts as often recommended. (e.g. techbrief_security.pdf)

The users being able only to read/write their own records, but the whole set being easily maintained and operated, calculated upon etc for administrators.

What are the cons? How get rid of the 'no access' screen for no access records?

What about using portals w account based keys instead of record privileges?

Part of the reason I am posting is I can't even get past the privileges setup. Please see enclosed simple file w one Admin (default login) and one User (shift/alt when opening). What am I getting wrong?

User gets nothing but the ugly 'no access' and can't even navigate, though she should have access to two records.

Using FM Advanced 8.0v1 (an issue?) in XP.

Accounts.zip

[Steven H. Blackwell]

Do update to8.0v3.

Regarding the badges, you can eliminate them by doing a GTRR based on the Account. Also, any finds will return matching records but exclude those to which a user has no access.

I'd avoid the "account based keys" concept. Too easy possibly to manipulate the keys.

Steven

[bme]

Thank you Steven for your swift answer!

I've upgraded to v3 but the problem remains.

I appreciate the GTRR (go to related record) technique, but my user account cannot even see its own records.

This might be below the general knowledge level of the forums, but I have enclosed a screenshot of the account settings of the generic test db.

Not used to post-6FM, I am propably just missing something obvious.

Cheers

[Steven H. Blackwell]

How is the value in the field Creator being entered? If by the auto-enter on creation method, be sure you selected Account Name and not User Name.

Also, try this formula instead:

Exact(Creator; Get(AccountName))

for the RLA test.

Steven

[bme]

The value is auto-entered (Account name, yes) but editable for testing.

I tried the Exact(Creator; Get(AccountName)) formula, (thanks steven), checking the case (User/User) and field type (text) but it did not help, I get no access.

If you have got the time, please check the enclosed example file Accounts2, it is tiny and as generic as I could make it.

I realise that FM sets the case of the Account Name function at login. The Account name is not case sensitive as is the password, but the Exact function is of course.

I tested that possible error source as well without result.

Are you guys really setting record privileges this way? :

Accounts2.zip

[Fenton]

Your security was so "pessimistic" it was clinically depressed :-] You'd disallowed access to any layout or script. So they couldn't see anything no matter what. And you can't find their records without a script. So I turned those back on. You may choose to limit them later,* but they've got to be able see something, and run a "startup" script.

I changed your Exact() to just Creation field = Get (AccountName). Your data had mixed case. And people are liable to log in either way, as the account name is not case-sensitive. If you want to enforce the case, then tell us; I couldn't tell.

With a file where every table is view access-restricted it is easiest to use a Find to get them to their records. A relationship works fine IF they have access to the table's record the database opens on; otherwise it's a Catch 22; they have no access to even a Get (AccountName) field, so the relationship can't resolve. A relationship works fine if you have another unrestricted table to start from.

Another action you must control is Show All Records. FileMaker will automatically restrict other Finds to the access-restriction; but Show All Records overrides that. So script it. I'm using the same script as the startup; but you may want slightly different steps for Show All. You need to decide whether the Admin also wants to Find their own records at startup; even though they can see all.

One other point. Your User privilege set had "All" as the Menu privileges. It should be either "Editing Only" or "Minimal". All allows such things as Replace Field Contents [], and a few other dangers.

*It is very cool that removing access to a script not only stops them using it, it removes it entirely from their visible Scripts menu (if any).

Accounts_fej.fp7.zip

[bme]

Thank you Fenton, saved my day.

Not trying to diminish my embarassing failure to test this option , I have to comment on the misleading formulation in the setup label.

In Swedish it reads "Access to data and design: All layouts/value lists/scripts without access privileges"

which without effort could be interpreted as "give access to data and design with no regard to privileges" or the like.

One last thing getting back to my initial concern:

Is this the way to manage records of an identical type for multiple users, such as e.g. time reporting records? I can see no reasonable way to address this with separate files for each user.

Any examples covering the basic access scripts and relations needed for a multiple user/single table/private records solution?