This is an old revision of the document!
The most important part of creating a new module is defining the module completely. Once you have clearly defined all the fields and the relation of the module with the other modules in the system the implementation is just copy paste and fill in.
This is the process I follow.
Module Name: this name will serve as the start for translation files and also as the internal name of the module. As with any name it should be significant and identify what the module represents but it also must be unique in your coreBOS install. I recommend prefixing a company identifier. The internal name must be a valid PHP identifier. For example
Name: | Just Log It |
---|---|
Internal Name: | cbJustLogIt |
Repository: create a repository to manage your module. For example, https://GitHub.com/tsolucio/cbJustLogIt
Now we have to define the fields, their validations and their layout. I use a template that defines the block name followed by each field definition in the order I want them to appear on screen. In this layout I also indicate which field will be the record link identifier and any special functionality I need the fields to have. This looks like this
Block: JustLogIt | ||||||
---|---|---|---|---|---|---|
columnname | uitype | fieldname | fieldlabel | displaytype | type_of_data | Comments |
doneon | 5 | doneon | Date | 1 | D~O | |
justlogitno | 4 | justlogitno | Log No | 1 | V~M | MODULE REFERENCE FIELD |
hora | 14 | hora | Time | 1 | T~M | |
smownerid | 53 | assigned_user_id | Assigned To | |||
operation | 1 | operation | Event | 1 | V~O | |
createdtime | 70 | createdtime | Created Time | |||
moreinfo | 1 | moreinfo | Value | 1 | V~O | |
modifiedtime | 70 | modifiedtime | Modified Time | |||
rel_id | 10 | rel_id | Related To | 1 | V~O | Accounts, Contacts |
rel_module | 1 | rel_module | Related Module | 2 | V~O | save the setype of the module rel_id if set in save_module |
donefrom | 1 | donefrom' | Done From | 2 | V~O | save $_SERVER['REMOTE_ADDR'] in save_module |
Block: Custom information | ||||||
Block: Description | ||||||
description | 19 | description | Description | 1 | V~O |
Note:
Next up are the list view fields. We have to choose from the fields above which ones will appear on the “All” filter, which ones appear in the popup when we try to select a re order from this module and also on any related list this module may be related to. I simply indicate them like this
List View Fields: justlogitno, fecha, hora, evento, value, Assigned To Related List Fields: justlogitno, fecha, hora, evento, value, Assigned To Popup Search Fields: justlogitno, fecha, hora, evento, value, Assigned To
Now we must define the relations this module has with other modules in the system. These will be indicated by the uitype 10 fields above and any many to many relations the module may have
Related Lists: - accounts
Next we must define the initial sharing privileges of the module. Module: public
Finally we must specify any additional functionality. This is where we will explain cron jobs, event handlers and any special widgets or operations the module just have.
Reached this point we have a clear idea of everything we need to create our module and we can start coding. The steps are
Finally create any additional logic that is needed: save module, eventhandlrs, cron,…
Now you are ready to install and test. Use the buildhelprscript install!module script .
Before installing I like to make a dump of the database so I can easily recover if i made a mistake and try again. Normally the errors appear in the manifest field definitions, typical copy paste errors.
In order to be able to send this module to any coreBOS you have to setup a specific structure. If the module is just for your install you can copy the files into place and use the install module script
The structure looks like this
The manifest in the top level is a copy of the one inside the modules directory