per jeremy

Including a plug-in as a dependency does not necessarily break the mFM credo as long as you document it. It’s worth avoiding if you can help it, but if there’s no other way, I don’t see why not. Do remember to double-check the license terms of the plug-in, in particular, whether you’re allowed to distribute it with your module, or if downloading it from the original source and adding it to the solution is something you’ll have to add to your install steps.

from david sparrow

Not sure if your module already handled this but...I like to setup a generic Account with almost no privileges which acts as a 'first time user' Account. Admin gives this generic login to new user, which in turn prompts the new User to create a new Account/Password - if successful, user record is also created in User Table.

if a privilege set is invalid when a user attempts to change the privilege, the value they selected is not reverted.

I’m coming late to the party but when using the CreateRecord script to create find request, I feel like adding an optional parameter that would allow for the find request to be omitting records rather than finding them. I’m having a hard time to think of a scenario where someone would want to omit the created record while in browse mode, so maybe the CreateRecord script could test to see we are in find mode before it runs the “Omit Record” script step.

Hey Darren, apologies for the delayed response.

This is the change I made to the script:

If [$UpdateRecord and not $NewRecord]
Enter Find Mode []
Set Field By Name [Get ( LayoutTableName ) & "::id"; $FindRecord]
Perform Find []
If [Get ( LastError ) = 401]
Perform Script ["CreateRecord 2"; Parameter: Get ( ScriptParameter ) & ";¶" & "$NewRecord = " & Quote("1")]
Set Variable [$!; Value:#Assign ( Get ( ScriptResult ))]
Go to Layout [original layout]
Commit Records/Requests []
Exit Script [# ( "id" ; $id )]
End If
Else

Create the record/request

New Record/Request
Set Variable [$error; Value:Get ( LastError )]
If [$error ≠ 0]
Go to Layout [original layout]
Exit Script [# ( "error" ; $error )]
End If
End If

And the upper part of the calling script looks like this:

"$CR_LayoutName = " & Quote("TableName: Blank") & ";¶" &

"$CR_RefreshType = " & Quote("none") & ";¶" &

"$UpdateRecord = " & Quote("1") & ";¶" &

"$FindRecord = " & Quote( TableName::idField ) & ";¶" &

messaging is blank in delete account error trapping. To test, try to delete an account that does not exist.

create a filtered portal in the module.

each person would have a record for each file.

currently there is no error trap processing after the subscript runs.

per dan smith:
Is there a reason this module cannot be used as a stand-alone file? I realize some users will want to copy the Accounts table to their data file, but installation would be much easier if they didn't have to. An example of this is PluginManager; I've set it up to only be used as a stand-alone/external file. The PluginChecker module is copied into any file that wants to use plugins, but I did not include instructions on installing PluginManager in a users file.

Our development methods and standards at Beezwax vary, and there's no mandate to always do (or not do) things a certain way, but my sense is that the majority of Beezwax projects rarely use multiple files for client databases. But I don't know to what extent (%-wise) this is true.

As you describe, I understand "integration as a separate file" is just an "alternative" for developers, so it's not really going against the grain. Besides, the target audience is other FM Devs, not just Beez.

1. This would be a good moment to survey Beez about "What % of the time do you use multiple files?" and "Do you do use multiple files, or the Separation Model always? often? ever?" and "Why? Why not?"

2. We should consider how Account Module aligns with popular high-level approaches and frameworks. This could also have marketing value, or even commercial value:

For example, does SeedCode or CoreCRM have Accounts built-in? Is it a less functional or less flexible approach? If so, could this replace and improve those other systems? What if you had an "Account Module for SeedCode Complete"?

(This is actually an potential idea for Modular FileMaker in general to gain more traction. Right now the MFM concept is very abstract, but if you tied your solution to another commercial solution it may gain commercial value-by-association. Not that we're necessarily looking to sell and support this module rather than keep it free, open source, but it's worth thinking about.)

What are the other popular (and useful) solutions, templates or frameworks to look at?

Let me know if this makes sense.

there is probably some unnecessary duplication for these two tables. Eliminate one.

There was, however, one part which confused me:

"For all files that will have managed accounts, create the privilege sets that the module will use.
The module expects that for each managed file the privilege sets are the same." 

That last bit appears in the docs right after the instruction to:

"Create a Value List in master file: ’Accounts_PrivilegeSet’
and add your privilege sets to the custom value list." 

A literal read of these instructions does make clear that only the privilege sets created before this procedure should be included in the value list. It just seemed odd that the value list would not include all the privilege sets.

This would have been unambiguous to me had I read something like:
"After creating your new privilege sets, and the two dummies, there is no need to return to ’Accounts_PrivilegeSet’ and add them afterword".

That would have left no doubt in my mind and I would not have asked the question.

You should create a custom menu for this layout that removes the new record menu item. The system layout should not have one and only one record.

also make sure that user is instructed to add a record to the system table

per jeremy

Can’t you use fmp URLs? (Or do you want to maintain server and CWP compatibility?) What feature are you wanting to add that requires "Perform Script by " functionality?

Per anders:

• FMP URL is best used with FMP 13 clients, not supported in previous versions

abstract the files and privilege sets for files into tables that the user can configure the values in.

Then in the create records script, we can loop through the values for the priv sets for the file.

Then the only change the user makes is to create branches for each privilege set and a create record step for each privilege set

abstract the value lists to tables (files, privilege sets)

in the SubScripts, if there are multiple files then the value of $errorOccurred will be nulled. Create a new variable that will be checked on exit.

David Sparrow

Also I've noticed that Priv Sets need to be known ahead of writing Scripts that assign to those Sets...seems easily breakable by someone editing Account Names and not knowing about the Script(s)...it might be a great idea to somehow reference the Module from within the Acct Manage Window somewhere - maybe a dedicated Account that is not Active but contains module description/instructions?

Modules are also more modular to the extent that they play nice with the rest of the host solution. Maybe take a look at the ModularFileMaker.org error handling recommendations (http://www.modularfilemaker.org/documentation/#Error_Capture_State), and see if you're comfortable adopting similar practices. (On another note, I'm considering switching to the same pattern for disabling script triggers, instead of the more elaborate custom functions I wrote. What do you think?)

The Accounts: READ ME script mentions more unified error handling in the road map. Here's what I'm doing in Barcode Creator, to give you another idea. For every error, the subscript "Report Barcode Creator Error" is called with a plain-text parameter.

Screen Shot 2015-01-12 at 16.35.25.png

The first line of that parameter is a human-readable (preferably user-readable) description of the problem, followed by YAML describing some relevant circumstances of the error, like the FileMaker error code and the text of the script parameter for a parameter parsing error. This is the script:

Screen Shot 2015-01-12 at 16.39.26.png

It adds "error" to the front of the error message if it isn't there already (which it never is within Barcode Creator), checks if it (1) should and (2) can display a dialog for the error, then exits with the error message as a Let notation result. I settled on this because it's the most concise thing I could come up with for the scripts encountering errors, the plain text parameter makes it relatively self-documenting and otherwise easy to read, and the Let notation result allows me to add non-human-readable data to the result passed up to the parent sub-script to support intelligent programmatic error responses. It also leaves the burden of any logging decisions and the option to override the module error messages to the host application, where it belongs. If you've had any other thoughts, I'd love to hear them.

I noticed that you're using the parameter-parsing calculation from the #Assign custom function. I'm using this more concise construction these days:
Set Variable [$parameterError; Value
EvaluationError ( Evaluate (
"Let ( [¶"
& Get ( ScriptParameter )
& "!="" ] ; "" )"
) )
]
I wanted to update the ModularFileMaker.org documentation using this instead, but didn't have the patience to figure out how to get Todd's WordPress installation to format a code sample. It doesn't guard for some of the possible problems that the #Assign function deals with, but I've never actually had such a problem in a working application.

It looks like there might be some confusion about what the "Public" folder is for under the ModularFileMaker.org convention. Scripts in the "Public" folder are designed to be called from the host application, but should not be modified. Any scripts that can (or need to be) edited, such as account script steps that need to have a privilege set selected, go in the "Configuration" folder.

Moving some dependencies to the configuration folder may make the installation process a little less sensitive to the order of operations. Alas, we can't handle privilege sets like this, but you can handle all script dependencies on fields, layouts, and value lists like this. The calculations for generating a new randomized password and welcome email text may also be good candidate configuration scripts.

per jeremy

Dan Smith had suggested that I make the module a stand alone file. I think this is what you are also suggesting. If not could you point out the differences? I have not done the analysis yet but I believe the module could easily be a standalone file with mainly just some documentation changes. I suspect though that you are suggesting something more radical.

A stand-alone file might just be the opposite of what I was suggesting. I like that about working with Dan; he and I seem to have diametrically opposite opinions about certain things, yet he’s still such a pleasure to work with! I suggested breaking your module into smaller chunks: a script-only module, and an interface/data module dependent on the scripting module. Making a stand-alone file solves the same problem, reducing installation effort, but by making a bigger chunk rather than a smaller one. That would be problematic for organizations that host their solutions at commercial FileMaker hosts who charge by the file, but problems of one target audience aren’t necessarily a great reason to restrict your options. Why don’t you try doing both? Make a stand-alone file that uses an interface/data module and a separate script-only module? Then developers using your module could adopt whatever balance of effort vs. configurability they want.

per dan smith:
'Accounts: ValidatePrivilegeSet ( privilegeSet )' script is bit by the Script Result bug recently being discussed in this group; if script parameters are not parsed the script result is empty.

if there is an error on deleting an account, should the account then be created (as it is now)

and if the account is created, why would there need to be a delete error message?

And, why is there an error message created for this function when there is no error trapping on exit?

all the scripts in folder 'Accounts: Public - Master File Only' could potentially be simplified by not evaluating the parameter, testing for error, or displaying an error. If you modify these scripts to never return a script result and exit the script immediately after an error occurs, then the called/calling scripts would be responsible for parameter parsing/error trapping. I don't know for sure this would work in this scenario, but if it could, then these scripts would look less cluttered and "scary" to developers when they are configuring the module.