Actually, no, it does not "suck". A short story:
Last week, I spent 2 hours finding and fixing a strange error message for a client. They had done something in Confluence Server that broke a space (not a user macro, but similar). Total accident, one of those things that could happen to anyone.
But 2 hours of expense - ok for big places, but this could have been the client with 20ish users - 2 hours of my time is 6 months of operating their Jira and Confluence costs!
Now consider that Atlassian Cloud supports millions of users who could make similar mistakes, and think through the implications of support time. It gives you a stark choice between
You can imagine that anyone choosing the first is going to have to charge an absolute fortune to supply thousands of expert support operatives who can dive in and fix absolutely everything really quickly.
Atlassian has gone with the second, to keep the price down.
Personally, if I were a real support agent, I would not want to support anyone who "has enough rope to hang themselves with". That's exactly what user macros *could* do, even though 99.9% of us will find a better use for the rope, that 0.1% it going to cost far too much and take resources away from others who need help.
Atlassian does actually provide a pathway for developing enhancements for Cloud. Its not as hard as people think. However, I do wish they would provide people with a way to create simple user macros in Cloud (i.e. no scripts, just text and existing macros). The excerpt macros can be used for this, but there are scenarios where it doesn't work well.
There's ways to avoid that though, for example:
- make it quick and easy for users to turn macros off or to see which ones are enabled
- disable them until a user manually performs a specific task that needs one then ask permission to enable that macro
- enable them only for a period of time
- only allow macros within an enhanced issue editor that must be explicitly requested by the user
- supply a "safe mode" to quickly disable all but core functionality
There's so many ways to avoid having macros always on and silently changing behaviour without user knowledge. Many of those approaches are tried and tested in applications where security is a concern such as when opening office attachments from MS Outlook or explicitly enabling Outlook macros before being able to run them.
I'm not saying the choice to not support user macros on cloud is right or wrong - only that there are ways to mitigate the risks involved.
@Vince Swann some of what you've described is actually part of Confluence (server and Cloud) already. However, user macros in Confluence aren't quite the same as macros in the Office suite, so I'm not sure how that exact model would be applied to Confluence. It sounds like you are thinking of automation scripts?
The issue with allowing user macros in Cloud is how they are rendered on a page because they can include scripts. Instead in Cloud you have the option to create either static content macros (simple, no scripts) or dynamic content macros (scripting allowed, but runs inside an iframe). Other Cloud apps that might provide automation features can only run with scoped permissions, which the administrator is aware of when they install it (like when you add an extension to Google Chrome).
I’ve got a couple of questions for you. Do you write technical documentation? What about technical documentation that references code and files from GitHub? In this article you will learn how to in...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events