Has anybody noticed this behavour in FMP 7.0v3:

- User is allowed to view and modifify all fields of a table, but not to
create or delete records -> Menu commands are greyed out

- A Script with full access will create a record

However:

- If I use a User Interface file and base a layout on the same table, a
script with full access will not create a new record, saying that user
lacks the privilege. It's the same user, and the privileges are the
same.

Is this a known bug?

Workaround: write a script in the data file, store the record ID in a
global, return to the user interface file, search for a global. And
something similiar for deletions. Not very elegant.

Better solutions?
--
http://clk.ch

It is more than likely the privilege set that is assigned to the user
you are logging in as. Go to File -> Define -> Accounts & Privileges
and then check out which priviledge set is assigned to the user you are
logging in as.

theduf <theduf (AT) adelphia (DOT) net> wrote:

The privilege set does indeed prevent the user from creating a record.
That's the whole idea. The menu items create record, dublicate record,
and delete record are greyed out.

However, a script running with full access power whould be able to do
anything. And it does in the data file, but not in the interface file.
Looks like a bug to me.
--
http://clk.ch

In article <1gyh5f7.1gba2jesiudfkN%clk (AT) freesurf (DOT) ch>, clk (AT) freesurf (DOT) ch
says...
Looks like a feature to me.

Lets say they allowed the behaviour you want:

A user with 'minimal' access to a data file, but power user access (the
ability to write scripts) in a UI file would be able to exceed his
authority in the minimal access file.

I can think of countless solutions where I -want- to give users the
power to build their own reports (ie give them access to script maker
and layout tools) -- that's one of the "Filemaker Advantages". But of
course you dont want to hand them the keys to the entire system.

Even more frightening is the potential for someone who knows minimal
access creditials to your system to create a file, add a file reference
using those minimal access credentials, and then write scripts with full
access.

Yep... definately a feature.

42 <nospam (AT) nospam (DOT) com> wrote:

That's not my situation. I'm afraid my English is not good enough, so I
failed to describe the problem properly.

The user's privilege is minimal everywhere. In particular, he is not
allowed to create records or to edit or write scripts.

Records should be created by scripts only (for various reasons). So I
write a script

Go to browse mode
Go to layout x
Create New Record

and I mark that script for running with full access (the new FMP 7
feature).

Effect: the scripts creates a new record, even if the user is not
allowed to do that.

Works in the data file, but not in the interface file.
--
http://clk.ch

In article <1gyhwaa.gsibb01nd1mngN%clk (AT) freesurf (DOT) ch>, clk (AT) freesurf (DOT) ch
says...
Yes I understood that. My comments were a 'what-if'. Clearly it makes no
sense to lock down scripts -less- when the user has MORE privileges.
So if you can't trust scripts on a 'power user' priviledge level, you
certainly aren't going to trust them on a 'restricted user' level.

Quite right.

Quite right.

Quite right.

Files are independant on some level. If you have a script in the data
file and you mark it full access. That file trusts that script because
the person who marked it full access has full access to that file.

However the data-file has no way of knowing whether the person who
defined the script in the INTERFACE file and marked it full access in
the INTERFACE file has any right to exceed their authority in the DATA
file.

So a script with full access in the interface file cannot be allowed to
exceed the users priviledge level in the data file.

To simulate your exact situation:

1) I have minimal access credentials to the data file.

2) I create a new file, add a file reference to the data file, create a
table occurence of the data table, and write a script to delete all
records in the data file. I mark this script full access, because I have
full access over this new file.

3) I create a user account with restricted priviledges.

4) I log into my new file as a RESTRICTED user. I run my 'full access'
script.

According to your model, my script should run and destroy the data file,
and its a bug if it doesn't.

Clearly that is a very bad model, ANYONE, including people who have only
minimal access to the data file could set this little fiasco up.

Fortunately this isn't the case, and Filemaker files correctly do NOT
trust 'full access' scripts in an external file.

-regards

In article <MPG.1d21e64ca2e0838e989b94@shawnews>, nospam (AT) nospam (DOT) com
says...
To really drive the point home: the data file has no way of knowing that
the PERSON who made the script full access in the INTERFACE file has
full access to the DATA file.

From the data files point of view practically -anyone- could have given
the script in the interface file full access.

It can't know, so it can't trust.

42 <nospam (AT) nospam (DOT) com> wrote:

Sounds solid to me, thank you. Another drawback of data separation.

Now I'm struggling between the two script approach and menu limitation.
--
http://clk.ch