User Management 4

by Karsten

UserManagement 4 is a solution to manage users and login procedures. Users are listed in a Filemaker table. Filemaker accounts are functional and per user group. User of the same group share the same settings. In the user table every user is assigned to a specific user group. Switching settings or groups can be done with a simple re-login.

The solution supports:

– login
– logout
– integrate your own Filemaker accounts
– integrate your own Menusets
– start and end dates for user access
– easy to enhance

In version 4 some bugs were addressed, specifically:
– fixed: landing page corrected (and an extra landing page added, to show different login scenarios for different accounts)
– fixed: upon closing the solution the active user name was deleted from the table

I just moved all downloads to a new improved website. Registration no longer is required.






19 responses to “User Management 4”

  1. Rob White says:

    Does UserManagement 2 handle multiple file databases account management?

    • Karsten says:

      Hi Rob

      For a multiple file solution, you need to set up the same accounts in every file. I myself use an interface file and one or more data files in my solutions. Every file has the same Filemaker accounts (by name and password), though their set-up can be different per file. When a user at login is assigned to a filemaker account, these rights will be used for all files opened.


  2. Gosmond says:

    If this is a repository for Filemaker modules, the modules should really be posted & downloadable directly from this site. If frequent version updates are necessary, simply make a note in the in-file documentation to that effect.
    I am not interested in registering on your site just to download a file.

    • Karsten says:

      Hello Gosmond

      Thank you for your input. You may voice the concerns of some others as well. Is this site a repository? It is not per definition and I checked this with Todd Geist before I made my uploads.

      The reason I ask for registration is simple: I want to understand what is going on, if there is interest at all, where people come from and so on. This will influence my future updates and developments. I consider it essential feedback for sound business. As I want to build a usefull set of tools, this is the way I choosed to go.

      I found that – especially from the States – developers refuse to register, create fake accounts, etc. That’s an attitude. It is not so much a problem with european developers. We do not spam, if that is of your concern.


      • Gosmond says:

        For me, I’ve long since passed the saturation point of registering for all the minor sites that want to “stay in touch” with me about products and services I may have only a very peripheral interest in.

        In this case, your item is in the gray area between “something I know I need and will use alot” and “something I may glance over for a minute and see that I’ll never use.”

        If you had 15 or 20 modules available I would probably take the trouble.

        If you’re interested in cultivating the widest possible audience for your content, you may want to consider a more open approach in which you offer an alternative download method that does not require registration, and then encourage people (but not require) to register via in-solution splash screen upon file opening.

        As far as perception goes, in general if a product is supposed to be “open source,” here in the U.S. the default attitude seems to be (and, reasonably I think) that it is released without any strings attached, including even registering an email address. At least, that is my perception & expectation.

        With respect,

        • Karsten says:

          Hi Gosmond

          Thank you for your reply. You have a valid point, no doubt. Be assured I will take your thoughts into account. As I intend to build exactly such a collection as you mention, it is all about building value. And sound business needs, beside the value of the product, sound relationships.


  3. Super says:

    I have a question regarding auto-login and then ask for user credential. Is this secure ? Someone once commented this is like letting someone into your house and then you ask who are you ?

  4. Karsten says:

    Hello Super

    The user management module is setup in a way that you are not able to proceed beyond the login screen, unless you have a valid user account.

    The question is thus: How secure is the login page? There are several considerations needed here:
    a) what are the security settings of the account you are starting up with (as defined in the file for startup)?
    b) how secure is the first login page? Access to any functions must be blocked from this page.

    If you create a secure login page, settings can be changed as soon as the user is validated and the login procedure goes on. While the UserManagement module has functionality, it must be properly embedded in your solution with your preferences.

    Does this answer your concerns?


  5. Tony Moller says:

    How would you set this up for a multi-file solution?

    • Karsten says:

      Hi Tony

      In a multi-file solution, you need to set-up the same accounts. I myself usually work with an interface file and a datafile. Thus the access from one file to the next must work. It does so smoothly, when the same accounts are implemented.

      While the account names and passwords must be the same, the settings of the account can differ from file to file.

      BTW: Version 3 is on the way, making it easier to implement.


    • Karsten says:

      Version 3 is now online.

  6. Tony Moller says:

    I too have an interface and data file(s) solution. How do you ensure that, once logged into the interface file (assuming that is the user’s start point) that the correct account is logged into the interface file?

    I’ll look at V3 although I was just getting a handle on v2 🙂


    • Karsten says:

      Hi Toni

      There is an automated login up and until the login screen. From there, if the user is found, there is a re-login with another account.

      In detail:

      If you startup, you are assigned a Filemaker account as defined in the file itself (File > File options). This is the Login-account, which is only valid for the login screen. It also comes with menu set “Login” and it routes to the login screen. This is defined in the file, it is secure and options can be edited as you prefer. The goal is to lead the user to a filemaker screen which is secured.

      From this screen, the user can login with his name and password – if his user account is active, otherwise he will be stuck in the login screen. If he proceeds, this is a re-login with one of the predefined Filemaker accounts (Account1, Account2, Account3, etc.) as assigned to his name in the user table.

      These predefined Filemaker accounts should be created in every file of your solution, with the same name and password. Only then the user will be able to edit data as you allow. Filemaker tries to access related files with the active account.

      Does this answer your question?


  7. Tony Moller says:

    I think so. Still working to get it all set up. I meant to say data file in my second sentence. Do you have to put the scripts into the data file(s) too, or just the various user accounts and permission sets?

    • Karsten says:

      Hi Tony

      The scripts are only needed to check you in to the system. There is no need to set-up scripts in other files, as access is realized through the accounts, not through the scripts.

      BTW: Just this very second I released the BulletField module, which is a nice enhancement for the UserManagement solution.


  8. […] THIS IS AN INTERESTING METHOD for managing users and logins from Karsten on Modular FileMaker. […]

  9. Steven Li says:

    Hi Karsten,

    Thank you for posting such a wonderful solution. I do have a questions regarding the integrated Filemaker account system: will your solution allow using the “auto-enter created by/modified by”? If I understand correct, this module is using pre-defined user names and passwords to manage the actual users groups from the interface. How could you track users editing data then?


    • Karsten says:

      Hi Steven

      Thank you for the flowers. During login the user name and first name are put into global fields. Use these globally available informations to write them into any field you like. Thus, it is not a field functionality, but must be scripted. Because it is scripted, it is easy to enhance and to manage.

      Does that help?


      • Steven Li says:

        Yes, that’s what I figured, I had the feeling that I should generate global variables with user initials etc to do auto-enter, didn’t realize it’s already there! However this will mean I must re-edit all the auto-enter fields already have… should have found this solution earlier =D

Leave a Reply

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