new module development: Packing Slips

[Guido1982]

Since I found the current Packing Slips repo to be quite outdated and missing functionality, I took it upon myself to create a training repo for myself. The purpose is to create a good packing slip module from scratch (scratch being the skeleton module). Here is the repo. I'd like some help on the main PHP file:

1. column_fields: What does this array do?
2. related_tables: Does this mean you have to activate this line to be able to show custom field names in related lists? But you can only set the related list columns in this file right?
3. list_fields: These are the fields used in the related list columns I think I know.. But am I using this correctly? I mean, I create a field for the related sales order on line 53, but can I do that this way? And how is the link text generated in this case?
4. list_field_name: Is related to the previous question. Is this where the link names are generated? And if so, shouldn't I use different column names then?
   

That's it for now. I'll proceed creating the manifest and get back if I have more questions.

[joebordes]

column_fields is automatically filled in the constructor with all the fields in the module. it is where all the values are saved when you load a record or when you save one


related_tables, this array adds sql joins to the query that is constructed when getting the values for a related list. You don't generally need to define it here because it is filled in automatically when need: https://github.com/tsolucio/corebos/blob/master/data/CRMEntity.php#L1845
it is just in case your module has some non-standard table relation that you want to get fields from

list_fields and list_fields_name are the array of fields that define which columns will be shown in the related lists of this module. Suppose you establish a related list on Accounts to your module, when someone goes to Accounts > More Information and opens the related list of your module, the columns that will be shown are the ones defined in these two arrays. This can be customized per module by the user using the List Columns Mapping:


http://corebos.org/documentation/doku.php?id=en:adminmanual:businessmappings:list_columns

Keep asking
Have a nice weekend

[joebordes]

BTW, we use the Packing slip module as a handy resource. A starting point to implement Master-Detail modules for some specific scenarios.

[Guido1982]

column_fields: Great, thanks.

related_tables: Ah, so bassically you could add some tables that do not follow the skeleton-protoype and use columns from it later on?

list_fields and list_fields_name: Wow, powerful that business mapping can override these. Very useful. But, suppose I wouldn't use Business mapping, am I using these arrays correctly here? Fot instance, can I use this relation to indicate that the lookup should be in accounts table? What will be automatically done here? Or should I use only my own module's tables?

Ah, that makes sense, using them only as a starting point.

Thanks for your help so far again!

[Guido1982]

In the meantime I've created a first version of the Manifest file. Here are my questions so far:

Specific to this manifest

1. In the example I used, in the 'related products' block, the sequence starts with 10, then moves on to 13 in the next field. But doesn't the sequence always re-start for every block? And shouldn't it just increment by one? I left it the way it was now because I thought maybe this is special for related product blocks.
2. I'd like to add the following customlink: In a salesorder detailview there should be an action that points to 'module=PackingSlip&action=CreateView&sourcerecord=SALESORDER_CRM_ID', as to create a packingslip from a sales order and auto fill the account, products and so on. How would I do this here? Or should I create a 'postinstall' script for this?
   

For general manifests

1. Forgive me for probably asking this a second time, but what does the 'generated type' mean?
2. How does 'presence' translate to the eventual templates? In the example file I used as a starting point, some fields were set to 0.
3. If I recall correctly, the info_type is not used anymore?
4. Can I use labels from the arrays in the files in the 'language' folder in the 'helpinfo'? I saw an example from vtiger 6 manifest handling for this, but I'm not sure if we have this also.
5. This one I also probably asked before: I use the 'entityidentifier' on the 'packingslip_no' field. I understand this is the ultimate identifier for an entity-module record, but why is it used inside a different field?
   

That's it for now, will report back after further work.

[Guido1982]

About the action link in salesorders: I read this page and then made this change to create a detailview basic link for salesorders. What I'd like to know: can we use array labels from the language files to set the action links?

[Guido1982]

And now for my most difficult question yet: how do I go about creating an inventory module? I could start with for instance the 'EditView.php' file from SalesOrders and move from there, but do I need to take any additional action to tell the system that this is an inventory module?

[joebordes]

(10-08-2016, 08:31 AM)Guido1982 Wrote: related_tables: Ah, so bassically you could add some tables that do not follow the skeleton-protoype and use columns from it later on?

Correct.

(10-08-2016, 08:31 AM)Guido1982 Wrote: list_fields and list_fields_name: Wow, powerful that business mapping can override these. Very useful. But, suppose I wouldn't use Business mapping, am I using these arrays correctly here? Fot instance, can I use this relation to indicate that the lookup should be in accounts table? What will be automatically done here? Or should I use only my own module's tables?

By default, you will be able to access all the uitype10 fields you put on your module. Account will be that type of field so your reference is correct, you don't have to do anything else and they will work with the mappings. If you really need to use the relation array then you should be able to use those fields transparently also. Note that I think I have used that array once, maybe twice in 10 years.

A note of warning: stay away from "standard" field names. For example, accountid. When you create a new uitype10 field referencing a standard module like accounts, contacts or potentials, DO NOT use accountid, contactid nor potentialid. We have inherited a lot of hard code references to these fieldnames. I mean there are pieces of code that specifically look for that fieldname and do something different spefically designed for that module. That is a hard to find non-expected functionality in your custom module. I usually use, accid, ctoid or potid (for example).

[joebordes]

(10-08-2016, 11:38 AM)Guido1982 Wrote: [*] In the example I used, in the 'related products' block, the sequence starts with 10, then moves on to 13 in the next field. But doesn't the sequence always re-start for every block? And shouldn't it just increment by one? I left it the way it was now because I thought maybe this is special for related product blocks.

If you specify the sequence you have to manually set the value and increment it accordingly. It does not increment automatically nor restart on a new block, it uses the number you give it.

(10-08-2016, 11:38 AM)Guido1982 Wrote: [*] Forgive me for probably asking this a second time, but what does the 'generated type' mean?

it is to distinguish custom fields created on the layout editor from main fields. It really isn't used much in the application, on the layout editor and also there is a hidden functionality on date fields where it won't set the default day to "today". Set your manifest fields to 1

(10-08-2016, 11:38 AM)Guido1982 Wrote: [*]How does 'presence' translate to the eventual templates? In the example file I used as a starting point, some fields were set to 0.

presence effectively hides the field. when you go to layout editor and hide a field, what happens is the presence is set to 1, when you show it it is set to 0
(yes, I know, the logic is inverted :-( )

(10-08-2016, 11:38 AM)Guido1982 Wrote: [*]If I recall correctly, the info_type is not used anymore?

correct

(10-08-2016, 11:38 AM)Guido1982 Wrote: [*]Can I use labels from the arrays in the files in the 'language' folder in the 'helpinfo'? I saw an example from vtiger 6 manifest handling for this, but I'm not sure if we have this also.

Yes, we do, helpinfo field is passed through the translator before showing on screen so set it to a reference and then translate that in your module's language file

Code:

<helpinfo><![CDATA[field_help]]></helpinfo>

then in your language file

PHP Code:

'field_help' => 'This is the help for this field', 


(10-08-2016, 11:38 AM)Guido1982 Wrote: [*]This one I also probably asked before: I use the 'entityidentifier' on the 'packingslip_no' field. I understand this is the ultimate identifier for an entity-module record, but why is it used inside a different field?

The entityidentifier directive is doing two things, one is defining the ultimate identifier of the module, the other is marking which field you want to show when this module is used as a reference. In other words, if some other module creates a uitype10 to your module, when you look at a record on that module (detailview or listview) you will see the fields that you have set the entityidentifier.

[joebordes]

(10-08-2016, 05:32 PM)Guido1982 Wrote: I'd like to add the following customlink: In a salesorder detailview there should be an action that points to 'module=PackingSlip&action=CreateView&sourcerecord=SALESORDER_CRM_ID', as to create a packingslip from a sales order and auto fill the account, products and so on. How would I do this here? Or should I create a 'postinstall' script for this?

About the action link in salesorders: I read this page and then made this change to create a detailview basic link for salesorders. What I'd like to know: can we use array labels from the language files to set the action links?

Yes, you have to do this in the postinstall event. The install process via manifest.xml can only modify the module being installed, if you have to add functionality to other modules it has to be done in the postinstall event.

The label is translated, the problem is that, at this moment, you have to add the translation to the module's language files. I have the solution to this designed and even implemented for some time now, I just can't get around to validating and releasing it.

For the moment add the translation strings to the salesorder files.