new module development: Packing Slips

[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).