Details about this thread
  • State Verified Answer
  • Replies 3 replies
  • Subscribers 313 subscribers
  • Views 787 views
  • Users 0 members are here
Related content from around SugarClub

Best Practices: Changing a custom module

Kristjan Geir Mathiesen

Hey guys.

I´m making my first module and I saw these best practices http://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_7.6/API/Application/Module_Builder/Best_Practices_When_Building_Custom_Modules/

But what is the proper way to maintain the module ?

Scenario: Custom module "pizza" is made on TEST. It is has already been deployed in PROD. Lets say I want to add a field to it or something.

Is that done in Studio on the PROD or do should I maintain the module on TEST and then redeploy (which seems to be NOT recommended)?

Probably just maintain in Studio, huh...

Thanks

KGM

Parents
  • 0

    Definitely avoid redeploying a module if you can, as that will wipe out any customizations you made to it as the doc notes.

    For things like adding new fields, Studio is the way to go!

  • 0 in reply to Logan Sackett

    Thanks Logan Sackett   What about bigger changes - would that call for something like export data, disable the module and uninstall on PROD, make those bigger changes of the module on TEST (including a new name, I´m guessing, to avoid redeploying), then use Module Builder to install "new" module on PROD and finally import data?

    Have a great weekend!

    KGM

  • 0 in reply to Kristjan Geir Mathiesen

    Once in PRD I make all changes in the Extension framework and treat the module as if it was a core Sugar module because redeploying will also delete relationships with other modules, and, if I'm not mistaken, dropdown definitions for your fields.

    I suppose you could export your data, back up any customizations, change and redeploy but I think it's more of a headache than it's worth.

    An easier route to avoid custom would be to make modifications for the module directly in code instead of using Studio, like adding field definitions by hand in code to keep the application from generating a _cstm table and _c fields, but you have to be careful to follow all the rules that Studio and Module builder would otherwise check for you in terms of name choices, vardef options etc. and you have to be careful about what you do and don't do in Studio. You could then use version control to commit and deploy your changes.

    HTH

    FrancescaS

Reply
  • 0 in reply to Kristjan Geir Mathiesen

    Once in PRD I make all changes in the Extension framework and treat the module as if it was a core Sugar module because redeploying will also delete relationships with other modules, and, if I'm not mistaken, dropdown definitions for your fields.

    I suppose you could export your data, back up any customizations, change and redeploy but I think it's more of a headache than it's worth.

    An easier route to avoid custom would be to make modifications for the module directly in code instead of using Studio, like adding field definitions by hand in code to keep the application from generating a _cstm table and _c fields, but you have to be careful to follow all the rules that Studio and Module builder would otherwise check for you in terms of name choices, vardef options etc. and you have to be careful about what you do and don't do in Studio. You could then use version control to commit and deploy your changes.

    HTH

    FrancescaS

Children
No Data