Differences

This shows you the differences between two versions of the page.

--- en:devel:corebos_hooks [2017/06/24 02:48]
joebordes [LINKS: Types and usage]
+++ en:devel:corebos_hooks [2021/01/11 01:59] (current)
joebordes [Supported events]
@@ Line 46: / Line 46: @@
 A **filter** will be called to do some tasks and will return a value, with which some action will be done in the application. Normally the returned value will be the same $parameter with some modifications. Filters use the **handleFilter($handlerType, $parameter)** method, which will return the new $parameter value.
-<WRAP center round important 80%>Events are launched for ALL modules and executed ALWAYS. That means that we must encapsulate or protect our event code inside a condition that makes sure we are in the correct module. Looking at the different examples you can see that almost all of them start with a
+==== Event Launching ====
-"//if ($moduleName=='whatever')//"
+Events are launched for ALL modules and executed ALWAYS.
-It also means that we have to be specially careful with the things that are done, our code has to be fast and efficient in order not to block the user experience and also resistant to errors.
+That means that we must encapsulate or protect our event code inside a condition that makes sure we are in the correct module. Looking at the different examples you can see that almost all of them start with a
-Although this may seem an incorrect approach, experience shows that it is extremely powerful.
+"//if ($moduleName=='whatever')//"
+<WRAP center round info 60%>
+This is the "de facto" standard
 </WRAP>
+It also means that we have to be especially careful with the things that are done, our code has to be fast and efficient in order to not block the user experience, and also resistant to errors.
+Although this may seem an incorrect approach, experience shows that it is extremely powerful for many situations.
+That said, the "save" events (and some others) support conditions directly in their definition and also dependency launching. These events have a "condition" column and a "dependent on" column.
+The **condition column** can accept expressions following this syntax:
+<code>
+The accepted grammer is:
+ *  comparision | inclause
+ * where
+ *   comparision is: SYMBOL == value
+ *   inclause is: SYMBOL IN listelement
+ *   listelement is: [ value (, value )* ]
+ *   SYMBOL can be: (a fieldname) | moduleName | id
+</code>
+for example, we can use expressions like:
+<code>
+moduleName in ['Contacts', 'Potentials']
+moduleName == 'Accounts'
+employees == '131'
+id == '74'
+rating in ['Active','Acquired']
+</code>
+The **dependent column** is a JSON encoded array of event handlers that must be executed before the one being defined. So you can ask the system to execute your event after some other event has finished.
 ====Supported events====
+<WRAP center round info 60%>
+Note that inside each event type the set of active events will be executed in order of creation (sorted by their eventid) as [[https://discussions.corebos.org/showthread.php?tid=1351|can be read here]].
+</WRAP>
 ===vtiger.entity.beforesave.modifiable===
@@ Line 65: / Line 102: @@
 ===vtiger.entity.beforesave.final===
 This event is an internal event that is launched after all other BEFORESAVE events when an entity is saved. It should not be used.
+===vtiger.entity.aftersave.first===
+This event is fired after an entity is saved, but before workflows and standard aftersave events but the local save_module() method of the object has been executed.
 ===vtiger.entity.aftersave===
@@ Line 105: / Line 145: @@
 ===corebos.footer===
-Will be triggered in the footer of coreBOS, when the whole execution has ended. If the logged in user is an admin user this event will be used to print out a time execution summary of the events.
+Will be triggered in the footer of coreBOS, when the whole execution has ended. If the logged-in user is an admin user this event will be used to print out a time execution summary of the events.
 This event does not receive any parameters.
@@ Line 111: / Line 151: @@
 {{ :en:devel:corebos_hooks:corebosheaderfooterhooks.png?700 |}}
+===corebos.popup.footer===
+Will be triggered in the footer of the coreBOS popup window when capturing a record in a uitype 10 field, when the whole execution has ended.
+This event does not receive any parameters.
 ===corebos.filter.listview.querygenerator.before===
@@ Line 143: / Line 187: @@
 ===corebos.filter.editview.setObjectValues===
-This event will be called when a new record is being created. It will receive the new CRMEntity object so you can add default values to any field using the column_field property. Obviously you could do other verification or functionality tasks.
+This event will be called when a new record is being created. It will receive the new CRMEntity object so you can add default values to any field using the column_field property. Obviously, you could do other verification or functionality tasks.
 You must return the object given.
-<WRAP center round info 75%>The [[https://github.com/tsolucio/coreBOSAddress|coreBOSAddress]] module has an exceptional example of how this works by filling in the address fields when creating a new record from it's related list.</WRAP>
+<WRAP center round info 75%>The [[https://github.com/tsolucio/coreBOSAddress|coreBOSAddress]] module has an exceptional example of how this works by filling in the address fields when creating a new record from its related list.</WRAP>
 ===corebos.filter.link.show===
@@ Line 159: / Line 203: @@
 ===corebos.filter.ModComments.queryCriteria===
-This event will be called when constructing the SQL query to retrieve the comments associated to a record. We must return a part of the //WHERE// condition that modifies the final query.
+This event will be called when constructing the SQL query to retrieve the comments associated with a record. We must return a part of the //WHERE// condition that modifies the final query.
 ===corebos.entity.link.before===
-Action launched BEFORE two entities are about to be related. Action receives the names and IDs of the records being related.
+Action launched BEFORE two entities are about to be related. The action receives the names and IDs of the records being related.
 ===corebos.entity.link.after===
-Action launched AFTER two entities have been related. Action receives the names and IDs of the records being related.
+Action launched AFTER two entities have been related. The action receives the names and IDs of the records being related.
 ===corebos.entity.link.delete===
-Action launched when two entities are about to be UNrelated (BEFORE). Action receives the names and IDs of the records being UNrelated.
+Action launched when two entities are about to be UNrelated (BEFORE). The action receives the names and IDs of the records being UNrelated.
 ===corebos.entity.link.delete.final===
-Action launched when two entities have just been UNrelated (AFTER). Action receives the names and IDs of the records being UNrelated.
+Action launched when two entities have just been UNrelated (AFTER). The action receives the names and IDs of the records being UNrelated.
 ===corebos.filter.preSaveCheck===
 Filter launched before starting the Save process. Will receive, the $_REQUEST variable and the current object trying to be saved. It must return, besides these two input parameters, an error status, an error message, an error action and an array of variables to return to the edit screen the process was initiated from.
+[[en:devel:corebos_hooks:precrud|You can read a little more about this filter here]]
 ===corebos.filter.preEditCheck===
 Filter launched before starting the Edit process. Will receive, the $_REQUEST variable, the Smarty object and the current object trying to be edited.
+[[en:devel:corebos_hooks:precrud|You can read a little more about this filter here]]
 ===corebos.filter.preViewCheck===
 Filter launched before starting the Detail View process. Will receive, the $_REQUEST variable, the Smarty object and the current object trying to be viewed.
+[[en:devel:corebos_hooks:precrud|You can read a little more about this filter here]]
+===corebos.filter.preDeleteCheck===
+Filter launched before deleting a record. Will receive, the current object trying to be deleted and must return a boolean indicating if the action may proceed or not and a message to show in case it cannot.
+[[en:devel:corebos_hooks:precrud|You can read a little more about this filter here]]
 ===corebos.audit.[authenticate|login|login.attempt|logout|action]===
 Actions called on the indicated events
+===corebos.filter.inventory.getprice===
+When the application requires a product/service price, it will get the unit price field from the database and then call this filter with some information so we can calculate some other price to be returned.
+This filter receives these parameters:
+  * the unit price
+  * the discount (always 0 as the application does not natively calculate this)
+  * an array with these values:
+    * inventory module we are on
+    * module id if we are editing
+    * accountid (maybe 0 if not selected)
+    * contactid (maybe 0 if not selected)
+    * productid/serviceid
+    * related_module
+===corebos.filter.announcement===
+return the announcement to show. permits creating dynamic announcements
 ====Custom Permission Hooks====
@@ Line 231: / Line 305: @@
   * [[en:devel:corebos_hooks:popup_query_hook|Popup query hook]]
   * [[en:devel:corebos_hooks:related_list_hook|Related List hook]]
+  * afterImportRecord
 ===== LINKS: Types and usage =====
@@ Line 255: / Line 330: @@
 |LISTVIEWBASIC|Button on the top of the list view of a module|
 |LISTVIEW|Hover menu on the top of the list view of a module that contains the link|
-|HEADERLINK|Hover menu on the top of the browser screen that contains the link. It appears next to the Prefrences icon and is a global action link|
+|HEADERLINK|Hover menu on the top of the browser screen that contains the link. It appears next to the Preferences icon and is a global action link|
 |HEADERSCRIPT|Permits the inclusion of a javascript file located in the application|
 |HEADERCSS|Permits the inclusion of a CSS style file located in the application|
 |HEADERSCRIPT_POPUP|Permits the inclusion of a javascript file located in the popup screen of the application|
 |HEADERCSS_POPUP|Permits the inclusion of a CSS style file located in the popup screen of the application|
+|PRESAVE|Permits us to launch code when the user clicks on the SAVE button BEFORE the operation is done. We will be able to execute code in the PHP application and force the execution of a javascript function. The javascript function takes full control of the save process which means that it must submit the form if it decides to. In order to do that it will receive the parameters: edit_type, formName, action, callback, any parameters sent by the php code|
 <WRAP center round info 90%>Get more details in the [[en:devel:add_actions|How to add action links to a module]] development tutorial.</WRAP>
@@ Line 267: / Line 343: @@
 ===== coreBOS JavaScript Hooks =====
-[[en:devel:corebosjshooks|Read all about them here]
+[[en:devel:corebosjshooks|Read all about them here]]

User Tools

Differences

Page Tools

Site Tools