Account Name Privilege Sets

[SteveS]

I designed a FM 10.0 runtime application with several privilege sets, (full access, limited access, & read only access). I made default account names with associated privileges for this runtime.

When the end user opens up the program, the usual opening dialog box appears, ACCOUNT NAME:________ & PASSWORD:__________.

By default, the name of the current user logged in appears inside the “Account Name” field.

The end user must enter their default account name to access the program with associated privileges.

How can I control privilege sets without knowing the end user’s account name. I want to distribute this application and give the administrator privileges to assign account names.

[IdealData]

You may need to check out these

Get(PrivilegeSetName)

Get(ExtendedPrivileges)

[SteveS]

I appreciate your direction “IdealData” and I believe I must do a lot of in-depth reading on this subject. I assumed many developers using FM Advanced have run into the same predicament. If anyone could provide me with a detailed explanation it would be greatly appreciated.

[Vaughan]

How can I control privilege sets without knowing the end user’s account name. I want to distribute this application and give the administrator privileges to assign account names.

You cannot know the end-user's account name.

But the solution needs an administrator account, so create a generic account, say with the name "admin" and a default password. Then encourage the user to change the password on first log-in (this can be done within FMP scripting).

The end user can create another administrator account and delete the default one if they desire.

[SteveS]

I set the default account name and prompted the user to change the default password with no problem. However, I did not see the change account name option.

[Vaughan]

No, account names cannot be changed, at least not directly. The old account has to be deleted and a new account created.

[SteveS]

Vaughan,

I appreciate your input and assistance.

I always try to work out problems that I encounter and keep on trying to figure out a solution.

I tried the Add Account script, Add[AccountName:Get UserName);Privilege Set;"My previously defined";Expire Password]

I thought I was almost there but got the "This name is already in use, please provide unique name," error message.

Thank You

[Vaughan]

Did you delete the old account first?

Rather than setting the account name to the "username", I'd script the process to prompt for the name of the account to create. It could be possible that the username that is set up in FMP's preferences is not what the new account should be called.

I was just thinking that a solution to the problem might be to create an admin account when the solution is first run. The opening script can trap whether the file is opened with the default account and if so prompt to create an new admin account.

The user can enter an account name and password, and if the account is created without error the default account can be either deleted or made inactive.

If the user decided not to create a new admin account, the default account stays in place. The user will need to use this to open the file and the prompt to create a new account will run again.

The default account will have to be named something that is not likely to be chosen as a real account name, otherwise the prompt-to-create-account process will run again.

This could be avoided by setting a "don't prompt to create admin account" flag in a prefs table instead of deleting the account.

[SteveS]

Vaughn,

I just seem to have problems with this, must be on my end. I can change the account name but cannot change the user name. I think I will just keep the runtime solution the way it was, assign the user's their account names, and user names, with associated permissions.

Thank you.

[bcooney]

Steve,

User Names are quite different from Account Names. A user name is the name that appears in FM Prefs. It is easily accessible to users, and therefore unreliable. In fact, I wish they didn't exist because they cause so much confusion for people just learning Accounts and Privs.

So, avoid Get (UserName) entirely. What you want is to create an account, Admin, that is a full access account. This account will be able to create additional accounts and assign them to the existing privilege sets.

You can build an entirely scripted module for this ( See this FM Advisor Article ), using the Accounts script steps. As Vaughan points out, you can't change a priv set via scripting, but rather delete the account and recreate it with a different priv set.

I would assume that you do not want to let the Admin add priv sets. This probably doesn't make sense as your scripts that limit access based on priv set wouldn't be aware of this addtl priv set.