I am learning a lot about managed vs. unmanaged solutions these days, and I definately see a lot of benefits using managed solutions in production.
I see that the recommended pattern is to have a development environment where you work with unmanaged solutions, exporting both unmanaged and managed versions of the solution, and finally deploying the managed solution to production (and possibly to a staging environment first for testing).
This is all very nice and clean, but not without pitfalls. I recently experienced the following scenario:
1.
We used the above pattern to create and deploy a managed solution for the account entity and install it for a customer. The solution contained among other things a form and some other stuff for integration with a legacy system
Sketch:
Managed section
Field A Field B
Field C Field D
2.
Without my knowledge, the customer went ahead and customized the account form using the 'customize' menu. What he did, was to create a new form section, and move some of the custom fields included in our managed solution from the original section to the new section
Sketch:
Unmanaged section
Field A Field B
Managed section
Field C Field D
3.
Since this is an unmanaged change, it takes priority over my managed changes, wrecking havoc to the form layout afer I did some other changes (deleting some other fields and changing the order of some fields on the form)
Resolution attempts:
I have tried re-installing the solution of course, also with the 'overwrite customizations' option that promises to overwrite unmanaged customizations to the entity, but that does not change anything.
I also tried removing the new section and the fields that were moved as an unmanaged customization (using the customize menu) and then reinstalling the managed solution, hoping that this would somehow 'undo' the unmanaged change and that the diff mechanism would detect that the fields in question were only present in the managed solution and that this would cause them to appear in the original location. But as it turned out, it seemes like I was only carving more changes in stone - this time telling the system to remove the fields from the form altogether.
Can it really be like this, that once you do unmanaged changes to a form, your managed form is just screwed?
Is there no way to force the managed form take priority again?
I can of course do some more unmanaged customizations to the form to put the fields back where they originally were, but that would just postpone the problem until next time I want to e.g. change the order of fields in the managed form - the unmanaged changes from last time still have priority.
It seems that my only options are either to start from scratch again, or to switch to an unmanaged regime for the account entity.
Lessons learned:
If this is as bad as it seems to be, I should probably have used managed properties to disallow customizations to the forms in my managed solution. If this was a custom entity I would have done so, but I thought this would be a bit strict for an entity like the account entity. Another lesson learned is probably to never give the customer sysadmin/customizer rights...
Would love some other thoughts and experiences regarding this.