IDE Object editor - Ability to check in and deploy an object while keeping its editor tab open

When troubleshooting objects scripts, one frequently needs to go through this workflow:

• check out + open an object/template in the IDE

• modify scripts/attributes

• close the editor tab (required to check it in)

• check it in (for changes to propagate to descendants)

• deploy it (and/or its descendants)

• trigger test conditions and check the logs

• find the object/template in the browsers and open it again

...and so on. This process results in a lot of opening and closing IDE tabs, and potentially hunting down objects in the browsers again. This cumbersome flow arises because objects can't have their changes deployed while still checked out, which is a requirement for safe multi-user editing in the galaxy.

If a solution were to be introduced to allow you to, check in, optionally deploy, then re-check out an object, without closing the editor tab, this workflow would be vastly sped up, expediting the troubleshooting process.

A solution must either be mindful of or work around the fact that checked out objects can't be deployed.

Here are two solution ideas. Each approach would be available to users as buttons in the editor tab top bar, placed near the existing "Keep Checked Out" and "Save and Close" buttons

1. Implement two new buttons "Check In and Reopen as Read-Only" and "Reopen as Checked Out". These buttons would allow the user to check in changes while keeping the tab open for an object (read-only, so not blocking deployment) while testing. They can then use the normal deployment methods to deploy changes. Once they're ready, the "Reopen as Checked Out" button (only visible in read-only editor tabs) will allow checking it out without having to hunt down the object in the browser again.

2. Implement a new "Deploy Changes and Keep Editing" button. This would allow the user to keep the item checked out (for multi user editing locking purposes) but allow them to check in and deploy their changes. This would require a second interaction from the user to pick what to deploy in the middle of the process.