Accounts: Modular User Account Management

by DarrenBurgess

Features Overview

Accounts allows for management of user accounts:

  • Create
  • Delete
  • Enable/Disable
  • Reset Password
  • Change Privilege Set
  • Configurable settings
  • Email User “Welcome” Email (including option to send a launcher file – launcher file sold separately 😉
  • Robust error trapping
  • Function success/error dialogs
  • Works with single or multi-file solutions where the privilege sets and accounts are the same in every file (although files can be excluded)
  • Includes basic UI for Account management
  • Uses standard Modular FileMaker methods for passing and parsing parameters.
  • All buttons and script calls include commented out parameters using # functions.  Scripts can optionally use # functions.

Error Trapping Notes

  • Before creation of a new account, the selected Privilege set is validated.  Creation is allowed if privilege set is valid.
  • When deleting an account, if the delete fails because the account does not exist in one or more files, then user is still given option to delete the Account record in the account table.
  • When changing account status or resetting a password for an account, the account is created silently if it does not exist in one or more files.


Standard MIT license.


Feedback and questions are welcome via or twitter: @darrenburgess.


Download Version 1.2

Download Version 1.3

Version 2.0 included a major overhaul to simplify integration and massively improve documentation.

Versions 2.01 – 2.04 added new functionality, documentation improvements and integration simplification.

Download Version 2.05 (from github).  This version just updated copyrights and license

Integration instructions are on GitHub.


29 responses to “Accounts: Modular User Account Management”

  1. Version 1.2 includes a few minor bug fixes and improvements to documentation. More details in the read me.

  2. Daniel Wood says:

    I pity the fool who doesn’t look at this file !
    Great module Darren thanks for sharing! I’m looking into it to see whether it is something we can adapt and use for our framework. One thing I noticed just briefly is the e-mail to send the account details is showing the password as “$Password=password” even when debugging is off.

    Some potential additional features could be changing a username (which can be done via deleting and re-adding the account with the new username), and being able to change privilege set without it resetting the users password 🙂


  3. Daniel Wood says:

    Oh and one other thing that would be useful is an Update feature for database updates. We do updates on small/medium systems by data import of the data from the live system into a development copy. However over time the dev copy accounts are just well out of date from what they are in the live. As part of our update procedure we have to “fix up” the accounts in the dev copy so that they match those in the live one, we do this by looping through user records and for each one deleting & re-adding the account with a generic reset password that users change on their first login after the update. this functionality would be great in this file for this use, basically a full reset of all accounts for post-update.

  4. Thanks for checking out the mod. Rockin good comments and thanks for catching that password email bug, Daniel. I had been considering a priv set and user name change function for a near future version. Makes sense cuz deleting the user record may be undesirable. A RebuildAllAccounts function would be great as well. I think it would be best for that function to rebuild accounts, but maintain the current selection for active and inactive accounts.

    Is there are way to change the priv set with out deleting and recreating the account? I think you were joking there, right?

    Let me know if you have feedback about the integration documentation. More work is needed there, I think.

  5. Super says:

    Question on Create Account in a multi-file solution. Let say I have 4 files. Creating Account for file 1 and 2 is successful but error occurs when create account in File 3. Is there a way to sort of ‘undo’ the entire creation ?

    • This is what I love about the mFM community feedback process. I never considered this possibility. You are correct – the module as it is now will create accounts in each file. If one fails, then the created account remains in the files where it succeeded. This is the case for all of the functions. I am going to have to rethink error handling a bit to ensure that it handles this scenario properly for each of the functions.

      One type of failure on account creation would be that the account already exists. In this case, the function should let that stand if this is the only instance of the account name in the table of accounts. The script should then continue on creating accounts in the rest of the solution files.

      I am realizing also that Account Creation should not be allowed if Account name already exists in the table. The script needs to trap for this earlier, before an attempt is made to create the account. This would make the previous paragraph moot.

      In the case of other types of account creation failures, all of the successfully created accounts should be deleted. I will have to look at the account error numbers to see which errors would warrant deleting created account in each file.

      And to top it all off, some of these features may need to be switchable with a setting.

      Hmmm… I wonder when the effort required to robustly trap for errors exceeds the value of error trapping.

  6. […] Accounts: Modular User Account Management – Modular FileMaker. […]

  7. Jonathan Fletcher says:

    I use a similar approach to user-managed accounts. It is not a trivial task. Every new option requires several script steps and an exponential increase in error trapping and what-ifs. And then you need to change the robot script in each of the remote files to match. It would be great if FMI would create a way to just give a person a privilege to manage accounts and assign privilege sets, and then propagate those across a finite set of files. One can wish.

    • Yes, it is a challenge. Would be nice if we could abstract the privilege set as well.

      To add to your comment, I am finding that upgrading the module in an existing deployment is challenging due to the amount of effort required to integrate. In most cases it may make most sense to reintegrate nearly from scratch to upgrade the module.

      I am looking at ways to pull some features into a settings script that would hopefully preserve any customization to the module that a developer may make in a specific solution (dialog text for one)

      • dansmith65 says:

        I’ve been writing my modules with this concept in mind. My goal is usually to prevent the user from having to edit any script outside the configuration directory, which makes updating the module easier. I did that for error handling in my JSON module. I also used it extensively in a currently un-published logging module: Have a look at the Config folder of the Log Writer: FM module for some samples of how I used this concept.

  8. Chuck Law says:

    Great idea and very well intentioned effort. The problem for me is that implementing it was very time consuming and ultimately not successful. The solution is very involved and probably best suited for those who can easily build this solution on their own. There is reasonable documentation, but ultimately not enough. The amount of studying what exactly is happening exceeded the time it would take to create my own solution. I do however appreciate the effort by the author to create the module.

    • Hey Chuck, Thank you for the feedback. My experience is that the solution takes 1-2 hours to implement into 3 file solution. I would be curious to know where the implementation failed for you. That would help me revise the documentation to be more clear.

      This is a tough module to write because of the many possible what-ifs and varied error conditions.

  9. Daniel Wood says:

    Nope no joke, there is no way to change the privilege set for a user without deleting & re-adding the account under the new privilege set.

  10. ShovelheadRider68 says:

    The script “Accounts: ValidatePrivilegeSet ( privilegeSet )” is incomplete. You have to follow the “Copy this block and adjust Add Account step for each privilege set in the solution” instructions in the script. Only “PrivSet1” has been setup to be verified. If you copy the “Else If” block, paste it below, and change “PrivSet1” to “PrivSet2” it works as expected.

    • There should only be one branch in the validate script in the shipping version of the module. Dev should add a branch when doing the integration. One branch for each privilege, change the if condition as you describe.

  11. ShovelheadRider68 says:

    Sorry about the confusion, I was actually meaning to comment on Daniel Woods comment about not being able to change privilege sets in the demo version of the file. He stated that you need to delete and re-add the user, which you don’t.

    To clarify, in the demo file, if you click on the privilege set for the “test” account and select “PrivSet2” you get an error stating that the privilege set doesn’t exist. If you go to the “Accounts: ValidatePrivilegeSet ( privilegeSet )” and add in “PrivSet2” as your instructions explain, it works fine.

  12. Greg says:

    Is a re-login possible that propagates to other files in the solution?

  13. […] second contribution to the library is Accounts.  This module offers wide range of functionality related to the management of user accounts in a […]

  14. Jonathan Fletcher says:

    So, how DO you change the privilege set of a user without deleting and recreating the account (not the user record, but the FMP account)? Inquiring minds want to know!

  15. If you have to pre load a lot of users instead of setting everyone to “password” I would recommend default password as: Right ( Get ( UUID ) ; 5 ) so that is somewhat random to each user.

  16. Todd Walker says:

    This is really helpful and gives me a lot of ideas! I was playing with v1.3 and noticed that when you click the Delete button a dialog box is presented asking if you really want to delete the account. It deletes the account no matter which button you click.

  17. benmiller says:

    After a successful and pain free install of this module (version 2.04) into a multi-file solution, on FileMaker 13, this morning I’d like to say thank you! I can highly recommend this. It works if you follow the README! (“…bang the rocks together, guys…”).
    Nice one!

  18. BT says:

    Please add most missing feature which is generating random passwords and sending them to newly created users.
    Than they can change it to their own after first login. The same default password for all new users currently is making all new accounts easy to capture.

    • BT:

      thanks for the suggestion. Although I believe it is already there, I will add it as an issue on GitHub.

      FWIW, I made the decision awhile ago to not email passwords from the module. Emailing in plain text a randomly generated password also is a security risk. Any thoughts on how the module might handle that?

  19. BT says:

    Every password reminder sends it within email. This is not as big issue as default password that everyone knows and can login as a new user before legitimate one do change it to his own.

Leave a Reply

Your email address will not be published. Required fields are marked *