As of version 2.0.0.151, all controls (components) described in the previous topic are created dynamically.


The feature may still evolve (that is the purpose of RadCORE).


You will be able to continue using it as before but we will see how to proceed from the informed version.



In the MAIN MENU training units (Ex: uMenu_BASICIS) we can now use the function:


rc_BuildMenuItemPermission( '', '<AIED>' );


See the example to add the customer registration item in the old and new way:


     Old way to add a menu item:


             rc_BuildMenuItem( mm.varA_MenuBasics, iSeqMenu, 'Clientes', 'clientes' );


     New way:( from version 5.0 )


             rc_BuildMenuItemPermission( '', '<AIED>' );



The purpose of creating the function above was to facilitate, but both ways are valid.



Right after adding an item to the MENU, you configure its respective permissions:


     rc_BuildMenuItem( '',  0, 'Clients tbl:clientes' );

        //permissions

        rc_BuildMenuItemPermission( '', '<AIED>' );

        rc_BuildMenuItemPermission( '', 'Licence Tab' );


In the USUARIOS_RESTRICOES table there must be a field to receive the permission parameters of each added option. When the "restriction field" is informed and it does not exist, it will be created.


Let's see how it works:


In the example above:


rc_BuildMenuItem( '',  0, 'Clientes tbl:clientes' );


we haven't set the "pRestrictionField" parameter, RadCORE then assumes that the permission control field is the table name or form name (whichever has been set, but, as a priority, the table name.


In our example, the second parameter ( 'customers' ), is the name of the table linked to this menu option, so you must create a field in the USUARIOS_RESTRICOES table following the model:




In the first permission line, using the parameter '<AIED>', the 4 standard items of the new modality will be created:


Acess

Insert

Edit

Delete


In the second line, we add a specific permission ('License Tab'), which is normal, since each form in our applications can have "n" permission options.



Each element added to the rc_BuildMenuItemPermission function has a sequence number to be used in conjunction with the rc_PermissionVerify function.


This function is who will control whether or not to allow access to each defined item.


In the example above, an inherited record with the options "AIED" will have the following sequence:



Let´s see frmBaseCRUD :


The function dm_rc.rc_PermissionVerify is responsible for controlling access on all screens and / or resources that need criticism.


Sintax:

DM_RC.rc_PermissionVerify ('screen name / resource criticized', 'table', position_permission_string)




Each button will have a call to the rc_PermissionVerify function.


Let's see the example mentioned above, in the customer register.



Access to the license tab of the customer registry receives sequential 6.


Through these examples you can add and control access to any item in your application.





Created with the Personal Edition of HelpNDoc: News and information about help authoring tools and software