So if you've got a sequence of Workspaces that are interlinked, you may have panels that are common to all of them, for example the side-menu on the Agent Audit and Alert Audit pages, so you basically have to create the same panel twice.
Instead, you could have either
A new panel type, which just mirrors a panel from an alternative workspace, that way it only needs to be changed or updated in 1 place. This may require each panel to have a "name" so you know what your mirroring.
:) I definitely like this one - I recall mentioning it to Nathen a while ago - probably when I last went through updating 8 or 9 Workspaces with the same HTML
Since the Admin User has control of the Manager, a lazy but simple method would be the ability to load HTML directly into the Widgets.
1. Fix a location on the Manager - something like ./Space/UserHTML/
2. Upload HTML to the correct locations
3. On the HTML widget, you could provide an extra option to select the HTML file from the list
4. When the modified date of that file changes, reload the HTML into the Widget... or load it afresh each time.
You could deal with permissions and zoning, by either permitting child directories for Team level (e.g. ./Space/UserHTML/DevOps is accessible only by users with DevOps permissions, whereas the root folder is readable by all teams) OR just enforce the naming convention (so Support.Menu.html can only be loaded by the support team.
A more advanced option would be to allow a widget to be loaded as an individual object (as searches are for alerts) that can then be uploaded into an App. This gives users more control and ensures that all the contents of the Workspace can be encapsulated into a single deployment action. However, I suspect this would require some more fundamental changes to how HTML widgets are dealt with.
