Under Review

Group multiple Studio changes into one session/system refresh

In version 7, any time a change is made in the Studio (new/updated field, dropdowns, layouts, etc.), it causes a system-wide refresh of all pages for all users. This makes it very difficult to make any Studio changes during business hours without affecting our users.

I would love the ability to start something like a Studio Session, where I can click a button to start the session, go and make a bunch of changes, and click end session to send all changes to the database in one go. 

For example, if I need to add 5 new fields and change a layout, it would be great if there could be just one update/refresh at the end of the session. Otherwise we're looking at 6 slow database updates and page refreshes for all users.

Bonus points for ability to save session changes and schedule the database update/refresh.

Mark Willert - add overview / confirmation of changes at end of session.

  • Salesforce.com has much more in place to enable safe development/configuration and testing. It allows you to make many types of changes, though not all, in Sandbox, package them together, validate them and deploy them to other instances (useful for UAT testing too). Even that wasn't comprehensive enough for my liking and some changes had to be redone in live (so had to be tested live). That would never have passed our production control rules in previous companies.

    I have not found a way of pushing any changes from Sandbox to live in Sugar except new modules. As an admin I work the same hours as the other users so I have to make studio changes at times which affect them. If there is a way around this I'd love to know. @MarkWillert, you suggest there is, but I can't see how. So... this idea goes a little way towards less disruption of users but a complete way of packaging up changes in Sandbox and deploying them to live is really required.

  • Definitely, care should always be taken when making changes to the system. It certainly wasn't my intention that this idea would promote bad practices, but more to limit that potential impact of the Studio as it already exists today.

    An overview confirmation of changes would be a great add, thanks for the follow up!

  • Hi Logan,

    it is just a matter of our experience - it IS possible to permanentely incapacitate a Sugar instance through Studio, so we strngly advise all our customers not to do it during business hours.

    I guess I can reverse my negative vote on this, but maybe you can expand the idea by adding something like an overview to the changes before deploying it.

    Greets,

    Mark

  • Thanks for the comment. Sure, the Module Loader could be used as a workaround to adding multiple fields at once; however, we would like to avoid installing a bunch of packages just for something as simple as adding new fields. We'd like to take advantage of using the Studio for simplicity where possible.

    Of course we always try to avoid making any changes while our users are in the system, but there have been cases where we've had to fix something in the middle of the day (i.e. after a recent upgrade, many of our subpanel layouts reset which needed to be fixed immediately). We don't have a dedicated position able to work on Sugar outside of business hours, hence the idea to plan changes during the day and then schedule the database update at a later time, when the system is not in use. The whole premise of this idea is to avoid disrupting our users - I don't really see how this could be viewed negatively.

  • Isn't this already implemented?

    You can always add fields through the module loader:

    http://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_7.5/API/Application/Module_Loader/Packag… 

    And layout changes can be saved without deploying them. But really... you make changes to a live environment while users are working on it? Personally, I see this as a big risk and don't think it is a good idea to encourage people to do it.

    In the early days of Sugar7, we had several cases of Studio changes that made the whole system unusable, and those were only fixable through log reading and developer knowledge, which is not a good thing to have on live environments.

    Have to disagree to this idea in its current form.

    Greets,

    Mark