Why is it not possible to create user macro's as non-admin user?

[Deleted user]

Why is a "normal" user not allowed to create macro's?

Isn't it the "normal" user who wishes to improve things he/she is documenting?

I dont't want administrator rights, but I do want to see what other options there are to improve our documentation by automating stuff. And I think it can be done by creating my own macro.. but well.. I am not allowed.. Why, why, WHY?

The same goes for why I am not allowed to see how our confluence is hosted, which is needed info to create this question..

[Nic Brough -Adaptavist- · Accepted solution]

Badly written or incorrect user macros can do damage ranging from page errors or making pages unusable through to taking down a Confluence system.  The ability to do that should never be given to general users, it has to be controlled by the people who have to look after the system.

If you want a new user macro, you could do it in your own development system and then give it to your admins to add for you when you've got it right in dev.

[Deleted user]

Thank you for your answer Nic,

That sounds fair enough.

But is there no possibility to give normall users the ability to create a macro that cannot have such an impact on the system?

So I can build my own confluence sandbox somehow? That would be a thing what I would want anyway, without others bothering with my useless changes.

[Nic Brough -Adaptavist-]

No, because almost all the power in user macros is granted by access to things that could break.  There's some minor formatting stuff you could do with them safely, but a whole "protection" layer would have to be wrapped in to prevent even those being allowed to do moderately bad things, and it's simply not worth it.

Your admins should have access to a "developer licence" for your Confluence sandbox - you can do a simple standalone install on your local machine and use the dev licence for it.

[Deleted user]

Thanks for the explanation. Too bad it cannot be done easily, or it might just also not be the thing I would want to have anyway. Since I don't know what I am looking for exactly, it doesn't make it easier to find out with just reading some documentation.

I will look into the developer license with our admin. Thank you for pointing me in that direction.

[Bill Bailey]

My belief is that anyone who is responsible for an organization's documentation needs to also be a qualified admin in Confluence. It would be impossible for me to do my job otherwise (in fact, I am the admin for our Confluence instance - just walled off from OS access).

[Nic Brough -Adaptavist-]

I'd argue exactly the opposite - people responsible for the documentation should not have to know how to administrate the tool they use for maintaining the docs. Ideally, it should be easy enough for them to use without caring about the admin at all.

An analogy - I have no idea how a car works, but I don't want to be a pre-requisite that I know how to refine crude oil into fuel for it before I can safely drive to work.

[Deleted user]

I agree with @Nic Brough -Adaptavist-, I should not have to care about the settings of my tool, only to be able to document whatever I am doing. Also it might be pretty easy to mess up the system of your whole company when just changing one setting. If everyone documenting here should be admin of Confluence, half of the company should be admin, also not really something you would want. On the other hand, I like to be able to see all settings of the tools I use, so that I know what can be usefull for me. But I am interested in why you think you need to be an admin to do such a job?

@Bill BaileyIs it because of the restrictions Confluence has for non-admin users, or would you always want to be an administrator of any tool you use? Or any other reason I did not write here?

[Bill Bailey]

Don't confuse a user generating documentation with a person managing the documentation process, which is what I am referring to. While I do generate and edit documentation, I am responsible for the documentation process, creating templates, generating needed macros, managing plugins, etc.  To my mind, there is no way to manage the doc process in Confluence without being an admin, and as a result, an expert in Confluence.

@Nic Brough -Adaptavist-, maybe you don't need to know how to refine oil for your car, but it would help if you knew how to change a tire. ;-)

[Deleted user]

Ah, so there is the difference in type of persons we are talking about.

I am not the person managing the documentation process, I am one of the people using the documentation application and I find myself doing things manually, that should be possible to automate. Since I am also responsible for automating our tests, it doesn't feel that weird to figure out how I could automate the documentation things we are making.

But still I am not an admin of the Confluence application and I don't want to be that either. Also I don't want to bother the Confluence admin with something I am not sure about how I would want to fix this and therefore figure it out myself.

[Nic Brough -Adaptavist-]

I'm not confusing anything, but you were very unclear about the role.  We've now got three - admins, authors and process owner.

Authors don't need admin.  Admins do. 

The process owner is a grey area.  To do that job, technically they still do not need admin, but they should be an experience user who knows the potential power of the software.  In some cases (especially in smaller organisations), you're going to find the process owner is one of the right people to have admin.  But in most places, they don't.  I've spent all of my time as a Confluence Admin being the admin.  With process owners who are not admins.  Best practice was to ensure we worked closely together, but they really did not need (or want) to be admins.

[Bill Bailey]

Yeah, well in smaller companies (100ish people), especially start ups, people wear multiple hats. So my opinion is that to be effective at owning the doc process with Confluence, one has to be an admin, and know how to work with Confluence from the OS command line up. Just not sure how I could really know the power of Confluence without being an admin.

Just my opinion based on experience with two separate companies over the last five years. And maybe I am a special case, I do it because I can, and because I can, they have me do it?

[Nic Brough -Adaptavist-]

Yep, that's what I'm thinking of as "smaller companies", you often wear more than one hat.  But that still doesn't mean the role of "admin" has to be to tied to "business owner of the docs"

To go back to the original question, one of the things about software as a service (i.e. Cloud) is the aim to get rid of the admin as much as possible, and provide a system that the users can't break.  So you remove stuff like user macros.

[Bill Bailey]

So if you get rid of user macros, how do you fill in all the holes in Confluence functionality for which there are no plugins?

[Nic Brough -Adaptavist-]

Use Server, and have an admin who knows how to look after it.  If you're on Cloud, you've deliberately chosen something with "holes", because the provider is not willing to let you break it to the extent you could with Server access.

[Deleted user]

I don't think that is how applications are chosen.

These days all you need to do is say you have a "cloud" application and people will buy it. Not because you should not be able to break it, but because they think now they can do their work everywhere and they don't have to be scared that their application is down.

Also people seem to think if something is called "cloud" you can do anything with it.

I have not yet heard the reason: We choose the cloud application because you cannot break it.

[Nic Brough -Adaptavist-]

You're right. 

It might happen, but I totally agree that almost nobody selects a Cloud application on the basis that "we cannot break it"

We do select Cloud applications because they do what we want and someone else has to deal with it breaking. 

This approach directly leads into those of us who have to deal with a system falling over to do everything we can to prevent failures.  i.e. "we do not want this to break for the customer, so we are not going to allow them to do anything that could break it"