Announcement

Collapse
No announcement yet.

Cannot assign permissions for custom form

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Cannot assign permissions for custom form

    Scriptcase v8.1.0005

    To reproduce the issue:
    1. Sync Applications (adds custom form to sec_apps and sec_groups_apps)
    2. Choose Groups/Applications" to assign permissions for the new form; you will find that all of the priv_ fields are greyed out - except for priv_access (the user cannot assign privileges to these fields)

    The issue is that the code (sec_sync_apps > events > OnValidate) is not writing the field "app_type" to the sec_apps table. In the "sec_form_sec_groups_apps" application / onscriptinit, it is trying to set arr_apps to the result set field "1" (app_type) - which is empty.

    To verify that this is the problem:
    1. Sync Applications (adds custom form to sec_apps and sec_groups_apps)
    2. Choose Groups/Applications" to assign permissions for the new form; you will see that all of the priv_ fields are greyed out - except for priv_access.
    3. Now edit the database table sec_apps to add the word "form" in the app_type for the newly added application
    4. Choose Groups/Applications" to assign permissions for the new form; you will see that all of the priv_ fields are are now accessible.

    It works with applications loaded into sec_apps by the security module but not with other (custom) applications.

    It (sec_sync_apps > events > OnValidate) also does not read the contents of the ini file to get the friendly url which is used to populate the description field in sec_apps.

  • #2
    hi betty, if you mean by custom form = control then i guess it must have the options working, not greyed

    please anybody from bugs team can confirm this for us? it is essential to have permissions for control application

    Comment


    • #3
      (I am using the scriptcase group security module)

      Scriptcase is using scandir to populate sec_apps with the list of files in the ".._lib\friendly_url" directory. They use the first 4 characters of that file name to populate the app_type field (but that's not working).

      So .. when I say 'custom form' I am saying that I built a form to add employees to a database table; ie. "form_employee". When I sync applications, it adds that new form to the sec_apps table and to the sec_groups_apps table; it does not populate the 'app_type' field in the sec_apps table. As a result, the options to set Permissions for insert, update, delete, export and print (in sec_groups_apps) are not active. To activate them, you have to add a value (ie. the word "form") to the app_type field in sec_apps.

      Further - if I later decide that I don't need that application "form_employee" and I delete it from scriptcase, scriptcase removes it from the "app" directory - but not from the friendly_url directory. So when you sync apps again, it loads those (no longer existing) applications back into the sec_apps table. You have to remove them from the ".._lib\friendly_url" directory manually AND, even after you do that, you have to remove them manually from the Applications (sec_apps) table (but you can use the "Applications" app to do that).

      Comment


      • #4
        Originally posted by betty View Post
        Further - if I later decide that I don't need that application "form_employee" and I delete it from scriptcase, scriptcase removes it from the "app" directory - but not from the friendly_url directory. So when you sync apps again, it loads those (no longer existing) applications back into the sec_apps table. You have to remove them from the ".._lib\friendly_url" directory manually AND, even after you do that, you have to remove them manually from the Applications (sec_apps) table (but you can use the "Applications" app to do that).
        this issue is since very long time back, we discussed it here over and over, I remember Albert Aducom made it very short and straight forward, don't play with security module, add it to the project at the last

        about the other issue, the friendly url, i didn't like the way it works, it is supposed to make this better, but as you could see (and I encountered the same exactly earlier) it is making things worse, it is just useless feature accordingly to the name it has so i just stopped using it, any app finally has its own folder, so why the bother!?

        but for the permissions, if I understood your description correctly, then it is again the friendly-url as well, as in friendly-url obviously takes the first 4 chars to determine the application type!! is that even possible!!! however, i use many application types without first 4 chars as form or grid but without the friendly url.. i do the same as you do (employees_form) or whatever, so this works ok with the permission... i guess if works ok without the friendly url then at least do not use it and keep this bug thread clear to flag it by SC guys and take the friendly url issues more seriously
        Last edited by MikeDE; 08-25-2015, 05:35 PM.

        Comment


        • #5
          This is how I fixed it

          Problem #1 - It does not populate the app_type field in sec_apps; causing the inability to assign permissions to update, delete, insert in sec_groups_apps. (It gets the app_type from the 4th line in the ini file that is found in the application directory, btw - not the 4th character).

          This is what I did to fix it:

          $vc_dir = ($this->Ini->path_aplicacao) ; <-- Added this line (the path was including the name of the current application (sec_sync_apps); I am truncating this in $file_ini to remove that
          $_app_type = '' ; <-- Added this line because after I added $vc_dir variable I was getting an offset error
          /*$file_ini = $this->Ini->path_aplicacao. "../". trim($friendly_name) . "/".$app ."_ini.txt";*/ <-- removed this line
          $file_ini = substr($vc_dir, 0, -14) . "/". trim($friendly_name) . "/".$app ."_ini.txt"; <-- Added this line; note that I am trimming $friendly_name because it had an embedded space in it

          (Still not perfect but better than it was!)
          Last edited by betty; 09-14-2015, 02:56 AM.

          Comment


          • #6
            Hello,

            This problem is already registered for our development team. As soon as I have some feedback, I will contact you.
            Best Regards,
            John L. Santos

            Bug Tracker Team
            NetMake - IT Solutions

            Comment


            • #7
              Thanks John

              Comment


              • #8
                It is still bug till now. But you can directly update the tables with the permission you want.

                www.LiviApps.com (Scriptcase International)
                www.OwenSolution.com (Scriptcase Indonesia)

                Comment

                Working...
                X