Dear group,

Until FM 7, I was used to a self made, internal FM user
login-authentication and right assigment to layouts and fields.
However, I have just started to migrate a 40 files / FM5.5 Server / FM
Pro 5.5 to FM7 and things look quite different to me. We have a
Windows 2003 domain, so I can use external authentication based on
Windows group. I could create groups just for the different FileMaker
profiles and then use this groups to assign rights in FMP. However,
managing rights has usually being a task delegated to somebody else in
my company. Before FM7, things worked great: I had Secure FM, a
personal login system and a users file where a rights manager could
setup user rights.

What is the best approach to do this is FM7 and later? (a link to a
sample file would be great)
Is it still necesary to have that user file to assign rights to
layout, fields etc.?

Take into account that the delegated rights manager knows nothing
about FileMaker and would like ot remain like that? He just wants and
easy layout with checkboxes... (this is what he has at the moment in
the 5.5 version).

TIA

Carlos

Carlos Pereira <carlosp (AT) nnhotmail (DOT) com> wrote:

Set up the external authentication to use whatever groups you currently
have, transforming into Privilege Sets and externally authenticated
Accounts assigned to them. Modify your login system to capture
Get(Accountname) on open and match it to your user table. Run whatever
routines you used to when a user signed in.

Then individual privilege bits in your settings can be checked against
and used pretty much in the old fashion. I agree that although just
about everything you can do with homebuilt, individual privileges can be
done with Extended privileges, we really don't want admins mucking about
inside Accounts & Privileges, particularly if you use a multiple file
structure, as makes sense for most large solutions.

And it kinda gives you double protection...the security of needing a
domain login, and then having the internal privileges. Just make sure
the Account names assigned by the domain admin match the user names in
your table, or have those account names recorded in the table.

Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting

Thank you Lynn,

I will take into account your advise.

One question: could you elaborate a little bit more on "particularly
if you use a multiple file structure, as makes sense for most large
solutions"? I think you mean a separation of data and interface in
different files. Am I missinterpreting your comment? Do you mean
something else? (besides data-interface separation, I do not really
see the point of having separated files in FM 8.0).

Regards,

Carlos

Carlos Pereira <carlosp (AT) nnhotmail (DOT) com> wrote:

Carlos, you still have to import working data into new file versions
during upgrades, no matter what version.

Say you have a 40 file solution in FM6. Where you used to have to
import only those files where structure had changed (unlikely to be all
or most of the 40), if you conglomerate all your tables into one data
file in FM8, every time you twitch a single table, you'll have to import
ALL the tables.

If some of your record counts in tables are large, this can mean a
significant investment of time. There are specific and serious reasons
NOT to develop on live files, including but not limited to the
experiences of more than one top developer reporting that a loss of
connection to the files during schema changes has resulted in the loss
(as in entire absence) of Table Occurances, data, or other structural
objects.

So most of us who use the data separation approach don't stick with one
data table for solutions of any size or complexity. We divide them up
based on two criteria: Anticipated record count and operational
function. So we'll have a data file for contacts, and another for
inventory, and another for sales and invoicing. We might make a single,
separate file for something like images intended to be stored inside FM.
Each holds all the tables applicable to that module, but unless the
solution is VERY simple and going to be relatively small, we don't do
"all tables in one file."

As you can see, this leads to duplication of Accounts & Privilege set
administration. Each file has to have duplicate A&P set up, and if one
uses internal FM authentication, it can become a nightmare.

Vince Mennano, former president of Waves in Motion, has come up with a
front-end system called Account Manager that will take care of all of
this. It's not simple, and building something like it your own self
could eat all your time.

http://fmnexus.com/am_explore.html

Or you can do what I do. Use External Authentication, capture the
Account Name on login, and keep a user table with individual privileges.
There are only a few actual accounts, and set up with forethought, they
never change. Users manage their own privileges as they always
have...the good news is that now we don't have to store passwords. We
only have to capture and match that account name.

Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting

Dear Lynn,

Thank you for your time and for a very clear and detailed answer. I
understand your point now.

I have taken a look to the Account Manager application. It looks very
good but, in my case it is not needed. Some of the functionality can
be found in the OS (I am in a Windows domain, and I will use external
authentication). For the rest, like you mention, it makes more sense
to develop a user control inside FileMaker (a user table), not for
authentication / account control /password control, but for access to
layout, fields, etc.

I can imagine that the model you propose (separation of data /
interface + separation of files according to record count and
functionality) is complex to implement and requires additional planing
compared to a "standard" one file - many tables design. In my case,
probably the biggest advantage would be the file size issue (I have
the chance to modify files during off use hours, so I do not need
neither have I ever worked in live files). But it worries me that I
need to create a complex net of relationships and scripts to make
everything work (more complex than if I were to use one file, anyway).

I will look for ready made samples of your model and give it a try, to
estimate the amount of work / learning needed.

Thanks again,

Carlos