11 Replies Latest reply on Jun 26, 2016 4:28 PM by cortical

    scripted record locking/unlocking

    cortical

      The use scenario is 2 users, and locking an Order record to prevent accidental editing.

       

      The routine user can run the script to lock the record.

      To unlock that record, requires a file close, and relogin as full access to unlock, then close file and relogin as the routine user, again.

       

      It would be preferable to allow the routine user (in this particular instance) to run a script to toggle the record lock status. But this is not working as might be expected.

       

      data separation file pair

      data table has number field: lock_code

      PS (routine_de) configured as records edit: limited : lock_status = 0

       

      login in to interface file as routine user: de

      if lock_status = 0, record editable as expected

      if lock_status = 1, no edit as expected

       

      reset lock_status script (interface file), runs with full access privileges:

      re-login as full access

      if lock_status = 1, reset to 0

       

      this throws error message - 'your access privileges do not allow you to perform this action'

       

      I have tried commit, flush cache, flush external and other peripheral unlikely variations, to no avail

       

      If I login to the file as full access, and run the same script to lock and unlock, it runs without complaint

      But if the initial login is DE, the script , despite instantiating a full access account before attempting the change status, baulks

       

      So despite the re-login, something is not allowing full access privileges even though the account is now full access

       

      If I login as full access, then script relogin as de, then the lock the record, the record remains editable

       

      What might I be missing?

        • 1. Re: scripted record locking/unlocking
          siplus

           

           

          What might I be missing?

           

          Maybe the given option of running a script with full access privileges ?

           

           

          See attachment.

          normal user is "regular" with pw "regular", Admin user is Admin without password, file opens with Regular account.

          • 2. Re: scripted record locking/unlocking
            cortical

            nope, it has run with full access configured:

             

            reset lock_status script (interface file), runs with full access privileges:

             

            thanks for the file, it works as expected, but not seeing any significant difference in config (yet)

             

            I'll play with it some more , and look for a point of difference

            • 3. Re: scripted record locking/unlocking
              Mike_Mitchell

              You said this was data separation. Do you relogin to both files with full access?

              • 4. Re: scripted record locking/unlocking
                cortical

                script closed the data file before relogin

                 

                can't monitor the data file for current account

                 

                ===

                I duplicated Siplus's file, and pointed an EDS at the original, renamed the original fields in the the interface, just to be sure...

                 

                It now behaves as my problem file set

                 

                the record is locked, but regular acct can edit it

                 

                 

                but relogin to both sounds like the nature of the problem

                • 5. Re: scripted record locking/unlocking
                  Mike_Mitchell

                  You cannot close the data file and expect it to relogin. This is because the data file will open automatically when you close it, unless you close the interface file first. Therefore, when you “close” the data file, it automatically reopens with the same privileges as you used to log into the interface file.

                   

                  I suggest performing a relogin in the data file and the interface file without attempting to close it.

                  • 6. Re: scripted record locking/unlocking
                    cortical

                    thanks again to Siplus and Mike.

                    Demo file attached if anyone interested (base on original file provided by Siplus)

                    accts admin (full access), de (data entry); both no password

                     

                     

                    <<You cannot close the data file and expect it to relogin. This is because the data file will open automatically when you close it>>

                     

                    Yes, I think I was expecting it to inherit the interface de account, if the interface was still running under de, but it seems to have been reopening under admin; timing or misinterpretation , I don't know which :-)

                    I added a b_data calc for the current account, and that made it easier to see when the accounts were changing

                    ===

                     

                    Now working. It is not actually necessary to re-login to both interface and data, only the data:

                     

                     

                    with a data separation file pair, the data file requires a relogin as admin, before the routine data entry account in the interface file, can unlock the record

                    the Auser file can remain logged in as the routine user,

                    the unlock script  runs a subscript in Bdata to temorarity re-login the data file as admin,

                    then unlocks the record, then reruns the  a Bdata subscript to  re-login as the routine user


                    files: Auser Bdata

                    PS: admin, routine_de

                    Accounts: admin, de

                     

                     

                    lock field in data file table

                    privilege set routine_de

                    data file PS custom record privilege; Edit ; limited: lock_status = 0


                    A routine data entry account (de) can lock the record
                    Auser script:

                    set lock_status = 1


                    To unlock the record using de account:

                    Auser script: toggle_lock

                    run with full admin privileges

                    parse the current account name to $_acct

                    IF PS ≠ full access

                    IF lock_status = 1

                    do subscript Bdata file called_relogin ; script parameter = (admin)

                    set lock_code = 0

                    do subscript Bdata file called_relogin ; script parameter = ($_acct)


                    Bdata SS called_relogin:

                    does not run with full admin privileges

                    $_account = script parameter

                    IF lock_code = 1

                    relogin as (admin) , dialogue OFF, hard code the password

                    IF $_account = (de)

                    relogin as de, dialogue ON to allow password entry

                     

                     

                    hard coding the user account password into the script is a non-secure approach admittedly

                    and for convenience only; this particular use case is a 2 user small LAN situation

                    it is also makes it easier for testing

                    • 7. Re: scripted record locking/unlocking
                      Mike_Mitchell

                      Simple answer: Full access is needed where full access is needed.  

                       

                      The separation model introduces several complications, most bothersome in the privileges are. You will find that "Run with full access" won't work unless you also mark any subscripts in the other file as well. And, as this example demonstrates, it's perfectly possible to have a user logged into the different files with different privileges (which can, at times, be beneficial, but often is a source of frustration when debugging.)

                       

                      Glad you got it sorted.

                      • 8. Re: scripted record locking/unlocking
                        siplus

                        hard coding the user account password into the script is a non-secure approach admittedly

                        and for convenience only; this particular use case is a 2 user small LAN situation

                        it is also makes it easier for testing

                         

                        A simple way of not hardcoding the admin password can be found in the attachment.

                         

                        Use the available script to login as admin, then look at it.

                        • 9. Re: scripted record locking/unlocking
                          cortical

                          thanks Siplus. That's a novel and nifty eSQL use.

                           

                          Along the way, I have crashed FM15 about 10 times, so have yet to get it as fully stable as it needs to be.

                          The problem has been a coding one, amidst playing with the variations, and triggering a wrong password in the Bdata for the user relogin - basically login fails and FM falls over ( presumptively due having an interface file open not pointed at anything 'valid')

                          Have to trap for that yet.

                           

                          I was thinking of creating a dedicated full access account in b_data, just for the purpose of editing the lock status.

                          Your neat eSQL might add some flexibility.

                           

                          The issue of  password as table records is perhaps 6 of one and half of the other vs hard coding it into the login script. But, a bit more deviant eSQL calc pulling the components from 'innocent' fields in several tables, that might be a worthwhile trick maybe the first primary key value in several tables... not secure but somewhat obscure.

                           

                          Given the use scenario, and that for the last 10 years or more , the prior db had been opening into full access with no user accounts... some flexibility can be accomodated

                          • 10. Re: scripted record locking/unlocking
                            siplus

                            Of course you can complicate the SQL with tons of clauses in the WHERE part, I just wanted to give an example of a parameter to relogin, calculated on-the-fly and not stored anywhere, not even in a $var.

                             

                            The nice thing about it is that you can have a prefs file from which you import data, XOR the hell out of it, then use the SQL on the imported table, then truncate the table.

                            • 11. Re: scripted record locking/unlocking
                              cortical

                              << what might I be missing?>>

                               

                              answering myself: a simpler alternative.

                               

                              I thought to myself: self, what about running the unlock as a full access privileged script in the Bdata file itself?

                              rather than the complications of swapping accounts

                               

                              run b_data script from a_user ( either as direct simple button, or script call; same results re account result)

                              sp = record_id

                              go layout, do find, unlock status

                              mssg: active account

                               

                              added a message at the last step for testing to return the current account in b_data, to confirm it is the ordinary user (de)

                               

                              Simple is good.

                               

                              Only potential minor issue may be a screen flicker on windoze.