Issues building new module with Module Builder (5.0.0.c)

[secant]

First let me say that I stumbled upon SugarCE and think that this is a great piece of work by all those involved!!! Thanks for doing such good things!!!

Apache version 2.2.6 (Unix)
PHP version 5.2.5
MySQL version 5.0.45-community
Operating system Linux

Sugar Version -- CE 5.0.0c

--Overview--

A new module was built, and all changes made, in Module Builder. The module was then saved and deployed from Module Builder. I did have to make changes after the deployment so I made those changes in Module Builder and then saved and re-deployed.


--Issue #1--

When the box is checked in My Account -> Layout Options -> Subpanel Links ... so that it is activated ... the new link associated with the new module was showing as 'LBL_NMBDF_NEWMODULE_SUBPANEL_TITLE' instead of showing the link as 'New Module' in all the related modules ... such as Accounts, Projects, etc

I changed the language file in .../custom/modules/accounts/language and added the label reference and all worked great in the Accounts Module! So, I proceeded to add language folders/files to all the modules that had relationships with the new module ... Opportunities/Projects/Calls/Meetings/etc ... in their respective ...<sugar-root>/custom/modules/folders.

So here is my question ... should I have added the language folders/files, as I did, to ...<sugar-root>/custom/modules/etc .... or should I have simply added the file reference to the appropriate language file in ...<sugar-root>/modules/folders? Instead of where I put them in ...<sugar-root>/custom/modules/etc

Since I am new to the software, I don't know which way will preserve the integrity of the new module built in Module Builder and allow for the new module to be removed if needed or changed if necessary or to be OK when future upgrades are applied.

Question -- Did I change the the language files in the proper place to ensure that future upgrades will see the changes and that I can remove the module if I so desire?


--Issue #2--

Question -- Is Issue # 1 a bug? If yes, how do I report it?


--Issue #3--

After deploying the new module, I found that the new module was not available in any drop down lists which had to do with Relating to other modules ... so, after some reading and research, I found that I needed to amend the following drop down lists in the drop down editor.
- parent_type_display
- record_type_display
- record_type_display_notes

Question ... Are there any other drop down lists that need amending?


--Issue #4--

Question ... Are there any other problems that I should notice or fix with the deployment of the new module?


Thanks to all in this forum and to all the developers!!

[DragonflyMaster]

--Issue #1--

When the box is checked in My Account -> Layout Options -> Subpanel Links ... so that it is activated ... the new link associated with the new module was showing as 'LBL_NMBDF_NEWMODULE_SUBPANEL_TITLE' instead of showing the link as 'New Module' in all the related modules ... such as Accounts, Projects, etc

I changed the language file in .../custom/modules/accounts/language and added the label reference and all worked great in the Accounts Module! So, I proceeded to add language folders/files to all the modules that had relationships with the new module ... Opportunities/Projects/Calls/Meetings/etc ... in their respective ...<sugar-root>/custom/modules/folders.

So here is my question ... should I have added the language folders/files, as I did, to ...<sugar-root>/custom/modules/etc .... or should I have simply added the file reference to the appropriate language file in ...<sugar-root>/modules/folders? Instead of where I put them in ...<sugar-root>/custom/modules/etc

Since I am new to the software, I don't know which way will preserve the integrity of the new module built in Module Builder and allow for the new module to be removed if needed or changed if necessary or to be OK when future upgrades are applied.

Question -- Did I change the the language files in the proper place to ensure that future upgrades will see the changes and that I can remove the module if I so desire?

Yes.
Put always your customizations inside <sugar-root>/custom/... folders: this will prevent them fo be overwritten when updating Sugar.

--Issue #2--

Question -- Is Issue # 1 a bug? If yes, how do I report it?

I don't know if that is a bug. To report bugs go here.

--Issue #3--

After deploying the new module, I found that the new module was not available in any drop down lists which had to do with Relating to other modules ... so, after some reading and research, I found that I needed to amend the following drop down lists in the drop down editor.
- parent_type_display
- record_type_display
- record_type_display_notes

Question ... Are there any other drop down lists that need amending?

No, those three only.

--Issue #4--

Question ... Are there any other problems that I should notice or fix with the deployment of the new module?

Deploying a custom module and playing with it is the best way to notice if it works or not. If you want to know which bugs still affect module developments, you can perform a search in the bug reporting page, just following the link I gave you above.

[secant]

Hi DragonFlyMaster

Thank you so very much for your input ... I been very impressed with the response from you all on this forum

I reported the bug in case it is not known.

Thanks again!!

Secant

[gwenstefni]

This working draft defines the mechanism for defining markup language modules that are compatible with the modularization framework used by XHTML. This includes a definition of the way in which an abstract module is specified, the way in which this abstraction is mapped into an XML DTD, and the way in which the resulting DTD module can be combined with other XHTML DTD modules to create new markup languages. In the future, it is expected that instructions will also be provided for mapping the abstract specifications into an XML Schema XMLSCHEMA. Note that the materials in this document were formerly part of the Modularization of XHTML document, but have been separated out for editorial purposes.
-------------
Gwenstefni


Link Building

[gwenstefni]

This working draft defines the mechanism for defining markup language modules that are compatible with the modularization framework used by XHTML. This includes a definition of the way in which an abstract module is specified, the way in which this abstraction is mapped into an XML DTD, and the way in which the resulting DTD module can be combined with other XHTML DTD modules to create new markup languages. In the future, it is expected that instructions will also be provided for mapping the abstract specifications into an XML Schema [XMLSCHEMA]. Note that the materials in this document were formerly part of the Modularization of XHTML document, but have been separated out for editorial purposes.
-------------
Gwenstefni



Link Building

[SR22Guy]

Thank you, my client hired me last week and this was one of the problem, I appreciate.

SR22