New accounts via scripting

[IdealData]

Oh what a disapointment that the Add Account script step allows you to supply calculated account name and password but not the privilege set

This is particularly important to me as I have 45 files that originally used common grouped passwords (because you could not maintain passwords in a hosted system). Now, in FM8, I'm going to bring back individual account/passwords - but I have 42 users! therefore 1890 accounts to create!

Bummer!

[Steven H. Blackwell]

Take a look at External Server Authentication. It is specifically designed to address your type situation.

The matter with the Privilege Set is intentionally designed in that fashion.

Steven

[IdealData]

You are right, of course, Stephen. However this will add a further level of complexity to an already large system.

Although I have downloaded

http://www.filemaker.com/downloads/pdf/techbrief_fm8_server_auth.pdf

Edited January 31, 2007 by Guest

[Ender]

What's the trouble with the privilege sets?

You can store the desired privilege set name in a field and refer to that when creating the account. Use If-Else branching to create the account with the right privilege set. This should work if the privilege sets are the same across the solution and they define the user class rather than what they can do within a particular file.

[IdealData]

Thanks Ender - but I think you missed this one. As Stephen confirmed this is designed to force you to use a pop-up menu - you cannot supply the privilige set name any other way, unlike the name and password.

Unless you know otherwise.

Edited February 1, 2007 by Guest

[Ender]

Like I said, If-Else branching:

If [ table::gPrivilegeSetName = "Sales" ]

Add Account [ Account Name: table::gNewAccountName; Password: table::gNewAccountPassword; Privilege Set: "Sales" ]

Else If [ table::gPrivilegeSetName = "Marketing" ]

Add Account [ Account Name: table::gNewAccountName; Password: table::gNewAccountPassword; Privilege Set: "Marketing" ]

Else If [ table::gPrivilegeSetName = "Operations" ]

Add Account [ Account Name: table::gNewAccountName; Password: table::gNewAccountPassword; Privilege Set: "Operations" ]

...

[IdealData]

Thanks Ender

It's an appealing concept and I did consider it.

My privilige set names are a little inconsistent, plus the conversion also introduced some new ones.

I estimate 6 hours to generate the new accounts by hand, but I'll probably spend a lot longer getting the scripts sorted.

If only I could extract the privilige set names!

[Ender]

You shouldn't think about the time involved as only the initial time to enter the accounts in each file. Think also about the time it will take to add a new account or change (promote/demote/deactivate) an account in the future as a result of turnover or growth. A scripted process would likely take more than 6 hours to set up, but will make account changes very easy in the future.

If your privilege sets are more based on the abilities to do certain things within each file (like "Edit", "View", "Manage" in one file and "Edit Own", "Edit All", "View All" in another), you could use the same type of branching, but have some of the logic contained within the calling script. The calling script would determine which privilege set is needed for each file based on the user's Job Title or something, and pass the right privilege set to each file via the script parameter (along with the account and password).

[Fenton]

The thing about the scripts that create new accounts is that they all will use the same-named table occurrence to a central Staff table, which also will have the the global fields for the account name and privilege set name (for the "if" tests). So the scripts can be copy/pasted or imported to the other files with few changes, at least in that part of them.

You still have to choose the actual Privilege Sets in each file however (I don't really remember if it can automatically pick the same one, if they're the same in all files; probably). So it's not a big problem if they're slightly inconsistent. In fact some simple files may have fewer privilege sets, i.e., what was 2 priv. sets in one file may be only 1.

You can in fact get the Privilege Set names with the DDR report. It's a little awkward to get a "list" with the html one, but you can see them. It's possible to extract from the xml one, with an xsl stylesheet. Or with a commercial app such as Inspector.

[IdealData]

FWIW in the end I did script the solution. Copied and pasted the scripts from file to file and then modified the privilege sets to suit within each file.

My solution has evolved over 15 years so there were quite a number of deviations.

In the end it took about 6 hours!