Best Practices: Changing a custom module

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!

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

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

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