(10-08-2016, 07:18 PM)Guido1982 Wrote: 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?

coreBOS does not have a Master-Detail solution. Even less with the Inventory modules.
The way the Inventory modules are programmed, the "Detail" part is saved internally in a non-standard table. This complicates everything and it is not the way I would recommend you solve this.
Since all the logic in the product lines of the inventory module is hardcoded it is hard to modify and maintain, specially in a way that would permit extending easily. The way the guys at ITS4You solved it when creating IssueCards and ReceiveCards (the base of the two modules available on github) is to replicate all the code and templates in their module. It is a solution and works rather well for us because we have two more inventory modules (for a total of 6). That is really enough in many of our installs.

When we need to implement a new Master-Detail module what we are currently doing is creating two modules; one for the master information and the other for the details. Then you use the related list. If you need more we program it, using detail/edit view blocks

keep asking

(10-09-2016, 09:03 AM)joebordes Wrote: 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).

So, it is okay to use this:



and here I mean the last two entries in the array, where I reference the standard vtiger_salesorder table and vtiger_account table, but I should not use:

Again the last two entries in the array, since I use the CRM's field/column names?

---

(10-09-2016, 09:28 AM)joebordes Wrote: 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.

So if I use sequencing, I should just use one continuïng sequence throughout the manifest file?

---

(10-09-2016, 09:42 AM)joebordes Wrote: coreBOS does not have a Master-Detail solution. Even less with the Inventory modules.
The way the Inventory modules are programmed, the "Detail" part is saved internally in a non-standard table. This complicates everything and it is not the way I would recommend you solve this.
Since all the logic in the product lines of the inventory module is hardcoded it is hard to modify and maintain, specially in a way that would permit extending easily. The way the guys at ITS4You solved it when creating IssueCards and ReceiveCards (the base of the two modules available on github) is to replicate all the code and templates in their module. It is a solution and works rather well for us because we have two more inventory modules (for a total of 6). That is really enough in many of our installs.

When we need to implement a new Master-Detail module what we are currently doing is creating two modules; one for the master information and the other for the details. Then you use the related list. If you need more we program it, using detail/edit view blocks

keep asking

I think I don't fully understand what you mean by "master-detail", but if you mean creating a PackingSlip module and relating products to it through a related list, then I think I will not implement it in this way. I will go for the ITS4YOU example and start out with their setup. I feel using a related list is blocking the workflow for something that I feel would be used quite often in a business. The number of steps to create packing slips should be minimal and as much as possible should be automated. But maybe I am missing your point.

Again, thanks a lot for all your answers. I'll get at it and come back here if I have any issue or questions.

---

I saw this in the "EditView.php" file:

Which stands for (I think) Basic and Advanced. Are these blocktypes still in use? Are these the blocks under "more information"?

$list_fields and $list_fields_name have to be synchronized and the same.
When I refer to field names I am saying it in general. If you add an account uitype10/capture field to your module, don't name it accountid.

each block has it's own sequencing which should start at 1 and be consecutive.

https://en.wikipedia.org/wiki/Master%E2%..._interface

I agree, it should be as easy as creating a single module, but it isn't, it always has a lot of logic and functionality related. Totalizing, grouping, dependencies are just a few of the hurdles that need to be considered.

info_type support has been deprecated, there is still some code there and you can get it to work if you need it, but in general it is bad practice: users don't know that there are more fields to fill in hidden elsewhere and it isn't consistent with the "more information" of related lists on detail view.

I will eventually eliminate it.

Also, for Master-Detail modules.
I want to start using Lighting Design guidelines for the application:

https://www.lightningdesignsystem.com/gu...es/layout/

(10-09-2016, 11:27 AM)joebordes Wrote: Also, for Master-Detail modules.
I want to start using Lighting Design guidelines for the application:

https://www.lightningdesignsystem.com/gu...es/layout/

Ah wait, master-detail is what is called "Listview" and "DetailView" in our application. But the detailview can either have inventory lines or not. Apart from that, I was planning to investigate a fixed header for the majorlabel theme, so we're on the same track there as well.

---

(10-09-2016, 11:19 AM)joebordes Wrote: $list_fields and $list_fields_name have to be synchronized and the same.
When I refer to field names I am saying it in general. If you add an account uitype10/capture field to your module, don't name it accountid.

I'll add a prefix to prevent conflicts, thanks!

Quote: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 :-( )

I noticed some fields also had their presence set to '2'. Is there a special reason for this?

---

No, master-detail is not list and detail view. Master-Detail modules are a special kind of one to many relation that exists in many situations. The typical example is an Invoice, you have a set of header fields and then many product lines, each line with it's own set of data and logic. Both the master and the detail, are, in themselves, normal modules with their own detail and list view.

Another example is a Project and Project Tasks, an insurance policy and it's set of liabilities covered