07-18-2016, 10:45 PM
First, each mapping type has it's own functionality and is used/launched depending on that. For example, the first one you indicate above is a Condition Query mapping, this one can be used as part of a Record Access Control mapping or simply can be used by your code whenever you need to make a decision. So let's imagine that you are creating some functionality that requires a set of account IDs, you could use the Condition Query mapping to get that set of Accounts, that way you don't have to create any special interface or functionality to get those accounts.
Yes, the origin id is the tabid. Truth is that none of the mappings I have created use it, you can safely ignore it, just put the module name.
Constants are simply text, nothing more, whatever you put inside the OrgfieldName directive will be concatenated. They are not calculated nor related to PHP in any way, just simple text.
Yes, it is actually triggered by the string {originalModule}2{TargetModule}, the code looks for a mapping with this name and if it finds it applies the indicated mapping. This is incredibly powerful to fill in fields. The typical: "set invoice due date to today plus 30 days" is a breeze with these mappings.
Global Variables are another incredibly powerful concept coreBOS has introduced. The idea is that you adapt the functionality of the code depending on the value of a variable set by the user. For example, imagine that we moved the list_max_entries_per_page variable which is now hardcoded in the config.inc.php file into a global variable. Now someone could go to the global variable module and create a record with a new value for the maximum number of records that will appear per page in the list view. Now that is easy enough, but the real power comes when you see that a global variable depends on the user defining the variable and the module it is being defined for, so you could define a list_max_entries_per_page of 20 for accounts and another of 100 for invoices while another user would define his own list_max_entries_per_page depending on his needs.
Then there is some additional magic whereas an admin user could block and make default or mandatory a variable for all users.
Really powerful!
Now your last code above. Instead of directly looking for a field mapping called 'SalesOrder2Invoice' we look for the mapping on the global variable module first, if it isn't found we will default to 'SalesOrder2Invoice' value. With this we accomplish that EACH user can have their own field mapping, so if one user need to set the Invoice due date to 30 days, while another needs it set to 90 days, they can do that by defining their own global variable.
Have a read at all that and keep asking.... :-)
Yes, the origin id is the tabid. Truth is that none of the mappings I have created use it, you can safely ignore it, just put the module name.
Constants are simply text, nothing more, whatever you put inside the OrgfieldName directive will be concatenated. They are not calculated nor related to PHP in any way, just simple text.
Yes, it is actually triggered by the string {originalModule}2{TargetModule}, the code looks for a mapping with this name and if it finds it applies the indicated mapping. This is incredibly powerful to fill in fields. The typical: "set invoice due date to today plus 30 days" is a breeze with these mappings.
Global Variables are another incredibly powerful concept coreBOS has introduced. The idea is that you adapt the functionality of the code depending on the value of a variable set by the user. For example, imagine that we moved the list_max_entries_per_page variable which is now hardcoded in the config.inc.php file into a global variable. Now someone could go to the global variable module and create a record with a new value for the maximum number of records that will appear per page in the list view. Now that is easy enough, but the real power comes when you see that a global variable depends on the user defining the variable and the module it is being defined for, so you could define a list_max_entries_per_page of 20 for accounts and another of 100 for invoices while another user would define his own list_max_entries_per_page depending on his needs.
Then there is some additional magic whereas an admin user could block and make default or mandatory a variable for all users.
Really powerful!
Now your last code above. Instead of directly looking for a field mapping called 'SalesOrder2Invoice' we look for the mapping on the global variable module first, if it isn't found we will default to 'SalesOrder2Invoice' value. With this we accomplish that EACH user can have their own field mapping, so if one user need to set the Invoice due date to 30 days, while another needs it set to 90 days, they can do that by defining their own global variable.
Have a read at all that and keep asking.... :-)
Joe
TSolucio
TSolucio