User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:devel:conditional_popup [2014/12/20 18:58] joebordes |
en:devel:conditional_popup [2020/07/11 18:50] (current) joebordes [Native relmod_id Method] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== How to open a capture popup with a preselected set of records. ====== | ====== How to open a capture popup with a preselected set of records. ====== | ||
| - | When the user clicks on the select icon of a capture field (uitype 10) a popup screen appears with the list of records of the module being selected. In certain situations it is necessary to pre filter the results for the user | + | When the user clicks on the select icon of a capture field (uitype 10) a popup screen appears with the list of records of the module being selected. In certain situations, it is necessary to pre-filter the results for the user |
| - | In fact the application already does this in various parts, for example when selecting a contact after having selected an account on an invoice. Only the list of contacts related to the account will appear. | + | In fact, the application already does this in various parts, for example when selecting a contact after having selected an account on an invoice. Only the list of contacts related to the account will appear. |
| + | |||
| + | ===== Open Popup Hook Method ===== | ||
| This tutorial will teach you how to implement such a feature for your uitype10/capture fields. | This tutorial will teach you how to implement such a feature for your uitype10/capture fields. | ||
| - | What we need to do to get this working is inform the popup code to launch a search on the set of records to return. This functionality already exists in the popup code, so we don't need to add any code there, we //just// have to pass in the right parameters to let the popup code know that it has to setup a conditional query instead of a full query. | + | What we need to do to get this working is to inform the popup code to launch a search on the set of records to return. This functionality already exists in the popup code, so we don't need to add any code there, we //just// have to pass in the right parameters to let the popup code know that it has to set up a conditional query instead of a full query. |
| The three parameters the popup code expects to see in order to setup a conditional query are: | The three parameters the popup code expects to see in order to setup a conditional query are: | ||
| Line 21: | Line 23: | ||
| if **searchtype=advance** then we have to send in this additional variable: | if **searchtype=advance** then we have to send in this additional variable: | ||
| - | * **advft_criteria** ={json object that defines conditions} | + | * **advft_criteria** =[{json object that defines conditions}] array of json objects which represent the conditions |
| + | * **advft_criteria_groups** =[null,{"groupcondition":""}] array or logical unions between the different groups. If you only have one group this variable is not needed. | ||
| where the json object has this format: | where the json object has this format: | ||
| Line 41: | Line 44: | ||
| vtiger_account:accountname:accountname:Accounts_Account_Name:V | vtiger_account:accountname:accountname:Accounts_Account_Name:V | ||
| - | the comparison operator | + | the comparison operator can be |
| * e: igual | equal | "=" | * e: igual | equal | "=" | ||
| * n: distinto | not equal | "<>" | * n: distinto | not equal | "<>" | ||
| Line 52: | Line 55: | ||
| * g: mayor que | greater than | ">" | * g: mayor que | greater than | ">" | ||
| * a: mayor que | greater than | ">" | * a: mayor que | greater than | ">" | ||
| - | * m: menor o igual | less or equal | "<=" | + | * m: menor o igual | less or equal | "<nowiki><=</nowiki>" |
| * h: mayor o igual | greater or equal | ">=" | * h: mayor o igual | greater or equal | ">=" | ||
| + | |||
| + | <WRAP center round info 80%> | ||
| + | Note that this JSON object is much more complex than is shown here supporting not only various fields but also different groupings of conditions. If you need a complex condition I would recommend creating a filter with the condition. On the filter, there is a nice editor that will permit you to add the fields, conditions, and different groupings. Then simply capture the save event to see how coreBOS creates the JSON object and use that. | ||
| + | </WRAP> | ||
| + | |||
| + | Now that we know what we have to do, [[en:devel:corebos_hooks:popup_open_hook|let's see some examples]]. | ||
| + | |||
| + | |||
| + | ===== Native relmod_id Method ===== | ||
| + | |||
| + | Before we had the search and open popup hook the application used a "parameter" based search method which is still in place (we just love backward compatibility). This system expects a pair of REQUEST variables to be passed in and will filter the results based on those using a specific query. | ||
| + | |||
| + | The supported set of modules is hardcoded and limited but in the end, the Popup code calls the generic getQueryByModuleField method where you can adapt your query based on the two variables for your modules also. | ||
| + | |||
| + | The two variables are | ||
| + | |||
| + | * **relmod_id** is the record id we must restrict the records to | ||
| + | * **parent_module** is the module of the relmod_id record | ||
| + | |||
| + | So you could open a popup passing in these variables and then detect them in your getQueryByModuleField method to adapt the popup query accordingly. | ||
| + | |||
| + | <WRAP center round info 60%> | ||
| + | vtlib_open_popup_window permits you to attach more parameters to the open window URL by adding them in the last ID parameter. You can see an example of all of this being used [[https://github.com/tsolucio/corebos/commit/967d27401be62cf7892436fe1a4ca7a84b35884a|in this commit]]. | ||
| + | </WRAP> | ||
