1 2 3 Previous Next 35 Replies Latest reply on Jun 11, 2014 3:35 PM by Stephen Huston

    Script 'Add Account' with external FM file

    robrickard

      I have been playing around with a couple of my databases and started down the path of the 'Data Separation Model'. What i can not figure out is how to script 'Add Account' on an external FM File. I have no problem with this on one FM. "Due to costs i do not have a server for testing solutions. From what i gather (but im not fully clear on) this may be much more easy with a server. Is it?

       

      The IWP solution im testing this on allows a guest user to log in with a form to Add a new user. Scripts then take care of the rest to 'Add User' and place it in the proper privilege group. But i can not figure out how to 'Add Account' on an external file. With out it all external data is locked away from the user. Is this possible?

       

      Thanks for the help and info,

      Im using Filemaker 12 Mac OS

        • 1. Re: Script 'Add Account' with external FM file
          wimdecorte

          It's not easier when the file is hosted.  You can use External Authentication on a hosted file and that cuts down the # of user accounts (you just need groups instead).

           

          Check out Security Administrator from nmci.com, it makes multi-file account propagation easier.

          • 2. Re: Script 'Add Account' with external FM file
            Mike_Mitchell

            The method I typically use is to script the account management using parameters to pass the account names around. You can call a script in the external file to spawn the new account and just pass the needed information back and forth in the parameters.

             

            HTH

             

            Mike

            • 3. Re: Script 'Add Account' with external FM file
              Stephen Huston

              Mike's is the method I used to add a full accounts management system to a 150+ File (not tables -- 150 files!).

               

              I built a master script in the "Master" (interface) file, and called "slave scripts" -- identical in each of the other files -- which received the parameters and set the account properties based on those variable values.

               

              Since scripts can be imported from file to file, it did require standardizing permission group names across the files to avoid having to tweak every added script in each file.

               

              The process of adding a new user in 150 files went from over an hour per new user to a few seconds with the scripted account management system in place.

               

              With a two file system, this should be a breeze. Just write the accounts creation script(s) in the data file, and set up the master script in the interface file to call it and pass it the account info as parameters/variables.

              • 4. Re: Script 'Add Account' with external FM file
                robrickard

                Ok - this sounds promising - Great info Mike and Stephen.

                I can see how to call on a script of another FM file, but im not sure how to send the $Var via parameters. How would i format that and then extract it or use it in the external script. I dug around and its not real clear to me. Testing it, im not figuring this out. Thanks for any help.

                • 5. Re: Script 'Add Account' with external FM file
                  robrickard

                  I figured it out. Simple little things.

                  Im passing three Global Vars for $$LoginID $$Password $$PrivGroup in the script parameters. Each has to be on their own line to be separated later and needs the ¶ for that separation. Also (what i forgot before - im relearing) the script needed '&' between each global var.

                   

                  so it looks like

                  $$LoginID&¶&$$Password&¶&$$PrivGroup

                   

                  The external script then uses 'GetValue ( Get ( ScriptParameter ) ; 1 )' to get the first line of data. Replace the 1 with a 2 for the second line and so forth.

                   

                  After that the rest should be as it would be scripted on the primary file in the first place. Honstly now that i figured it out - easy and pretty cool. This will be used a lot as im off loading data to several FM files. (unless i figure out there are better practices for what im trying to do).

                   

                  Thanks again Mike and Stephen for pointing me in the right direction. Good stuff!

                  • 6. Re: Script 'Add Account' with external FM file
                    beverly

                    Or:

                    List($$var1;$$var2;$$var3; ... )

                     

                    -- sent from my iPhone4 --

                    Beverly Voth

                    --

                    • 7. Re: Script 'Add Account' with external FM file
                      robrickard

                      You always have solid advice Beverly - thanks. That would be much better for what im doing.

                       

                      I tried that and it didnt work for me, but i bet it was that i forgot the 'List(...)' and only had $$LoginID;$$Password;$$PrivGroup.

                      • 8. Re: Script 'Add Account' with external FM file
                        erolst

                        robrickard wrote:

                        I figured it out. Simple little things.

                        Im passing three Global Vars for $$LoginID $$Password $$PrivGroup in the script parameters. Each has to be on their own line to be separated later and needs the ¶ for that separation.

                         

                        Two more “simple little things”:

                         

                        1. use whitespace liberally to increase the readability of your statements, like so

                        $$LoginID & ¶ & $$Password & ¶ & $$PrivGroup

                         

                        2. As for compiling lists, here's a better way: use … well, List():

                        List ( $$LoginID ; $$Password ; $$PrivGroup )

                         

                        And if you need this more often, there are entire methodologies, including custom functions, on how to pass named values, then read them (or create new variables) by name in the other script.

                         

                        EDIT:: oops, Beverly was faster …

                        • 9. Re: Script 'Add Account' with external FM file
                          robrickard

                          I saw custom functions to help with that - but im not sure why i would go down that path if the Global Vars will be passed this easy. Maybe if i was passing field data i could save the task of placing them in Vars... im still wraping my head around much of this as best practices and what is best for performances.

                          thanks again for all the help,

                          • 10. Re: Script 'Add Account' with external FM file
                            wimdecorte

                            robrickard wrote:

                             

                            I saw custom functions to help with that - but im not sure why i would go down that path if the Global Vars will be passed this easy.

                             

                            The Custom Function approaches will typically take care of passing the variables around in a safe manner.  If one of your vars for instance contained text with returns in them your approach would fail.

                             

                            Also as a tip: don't use global variables unless you absolutely need them. 

                            • 11. Re: Script 'Add Account' with external FM file
                              Mike_Mitchell

                              Rob -

                               

                              The return delimited list works perfectly well a lot of the time … until one of your parameters does or might contain a carriage return. Then you have to do one of two things:

                               

                              1) Escape the carriage return by substituting another character or string.

                              2) Use another method.

                               

                              One method is to use a name-value method. One way of doing this is given as an example in the Help in the Evaluate function, but it works like this:

                               

                              Evaluate ( "Let ( [" & source & "] ; " &  param & " )" )

                               

                              Your parameter will look like this:

                               

                              name1 = ”value1” ; name2 = “value2” ; name3 = “value3”

                               

                              and so forth. By using this method, you gain three benefits:

                               

                              1) You can extract any parameter you want (so your scripts become more flexible).

                              2) You don’t have to remember what position in the list a given parameter occupies; you just have to know the name.

                              3) Your parameters can contain carriage returns (which, if you’re using field contents as parameters, often is an issue).

                               

                              There are other methods for name/value pairing, but this is, if you like, the “next level” of parameter passing.

                               

                              Mike

                              • 12. Re: Script 'Add Account' with external FM file
                                robrickard

                                Why should i not use Global Variables unless 'absolutely' necassary?

                                 

                                Im not sure where that means. Is there a good article on best practices of using and not using Gloval Vars?

                                Most of my Vars are not Global, but i see needs for them and feel i use a lot.

                                I have a lot of scripts that call other scripts. This requires global scripts.

                                I also have some scripts that are used for a error message as a field merge. I can not see a way around it with out a global var.

                                I also track the user and what they can have access to which seems to be a better practice to use globar vars than to do a search each time a user requests access to a database.

                                If these are not best practices or there are other reasons i should not use global vars vrs searching each new record request please share. I still feel new to Filemaker and best practices. Lots i just dont know. I do plan on joining in on the Dev Conference in 2014.

                                 

                                Thank you for all the advice and knowledge. This community is amazing and so helpful.

                                • 13. Re: Script 'Add Account' with external FM file
                                  wimdecorte

                                  robrickard wrote:

                                   

                                  Why should i not use Global Variables unless 'absolutely' necassary?

                                   

                                  Im not sure where that means. Is there a good article on best practices of using and not using Gloval Vars?

                                  ...

                                  If these are not best practices or there are other reasons i should not use global vars .

                                   

                                  I'm not saying to not use them.  But to just use them only where you need to and nowhere else.  For layout merge variables: absolutely, that's the way to go.

                                  For making info available between scripts: not so much.  The preferred approach is to pass parameters to the other script.

                                   

                                  It's all about Scope, Lifetime and Visibility of variables. Those topics are not unique to FM, they apply to all coding environments and the best practices apply to all of them.

                                   

                                  Scope:

                                  you only declare the variable for the scope that it needs to be used in.  FM has 3 broad scopes:

                                  - the file

                                  - a script

                                  - a calculation (this is murky in FM because there are so many places where calculations can be specified: a field def, script steps, layout elements like visibility, conditional formats,...)

                                   

                                  Lifetime:

                                  Ideally you want your variables to have an automatic lifetime in the sense that when the scope closes the variables die.  The variables are cleared automatically by the program.  FM does that for all 3 scopes: $$vars get cleared when you close a file, $vars get cleared when the script ends and your Let() variables get cleared whent the calculation ends

                                  Where possible you want the program to clean up after itself and avoid having to do it yourself in your code.

                                   

                                  Visibility:

                                  That's typically where you run into problems by not limiting variables to their scope.  The value of a $$var is available in every script, in every calculation.  The value of a $var can be used throughout the duration of the script.

                                   

                                  If I declare a $var in a Let() function in a calculation for instance, like this:

                                   

                                  let(

                                  [

                                  $$var = "something" ;

                                  $otherVar = "something else"

                                  ];

                                   

                                  $$var & " - " & $otherVar

                                   

                                  )

                                   

                                  Then both $$var and $otherVar will still be visible when the calculation ends. $$var will be around until I close the file.

                                  If I really only needed them to get to the calculation's end result then I have to remember to clear them out, or risk accidental use of those variables values.  Or much better: not declare $ and $$ variables in the Let, use another notation like _var and _otherVar (there are no strict rules about naming calculation variables).

                                  Say that in my script I had already declared $var and set it to "my value".  Later in the script I do something that fires the calculation above.  Then $var will contain "something" and not "my value".  That may be you intention but it may not be.  That's not always understood by beginning developers.

                                   

                                  Going back to the thread's topic. the script that calls the subscripts to create the accounts probably does not need global variables.  If you use local variables and use some of the available techniques for passing parameters to the subscripts you can be assured that all variables will get cleared when the process is done.  Automatically.  By using global variables things like $$password will be available and visibile until you close the file or until you manually explicitly set the variable back to nothing.

                                  • 14. Re: Script 'Add Account' with external FM file
                                    steve_ssh

                                    robrickard wrote:

                                     

                                    I also track the user and what they can have access to which seems to be a better practice to use globar vars than to do a search each time a user requests access to a database.

                                     

                                    Hi Rob,

                                     

                                    Just a note regarding the above practice of storing access privilege information in global vars:

                                     

                                    If the solution is accessed using an FM Pro client, then a user who is accessing the solution with a copy of FM Pro Advanced will be able to view and modify the global variables in their session, hence providing an opportunity for an unscrupulous user to try to game your system and access more than they should.

                                     

                                    HTH & best,

                                     

                                    -steve

                                    1 2 3 Previous Next