we'd love to have a confluence space where the whole internal team can read the sites but only a handful of people is allowed to edit. A bit more information:
Giving all internal users a confluence account is not really reasonable. The extendet team is more aproximately 10 times the size of the amount of people who need to actually add or edit sites.
Allowing public access is not an option.
Does anyone have experience with a similar situation? I'd really like to avoid licensing a large number of people without the need to do anything but read content...
Is there maybe some sort of best practise for handling this scenario?
(I've of course used the search before posting , but the last related post ist almost 3 years old - maybe something changed in the meantime...)
Thanks in advance!
You have two simple options:
A third option might be a read-only dummy user that is shared, but the correct answer is anonymous access. If people have problems with a dummy user, you won't be able to debug it easily.
we had the same question. So we acitvate anonymous access but before you can access there is a window asking you if you are a member of our network or not. You have to fill in in your company login. That we solved with Single Sign On. So probably that would be a solution for you?
I am not sure how our database guru realized it. But probably the idea will help you.
What you are describing is more like a static web page which people visit from time to time to see what has been released for viewing ... that process is more using what the industry would call a "Content Management System" (EzPublish etc) where a few people create and a large number of people read ... like publishing a newspaper or magazine ... and who has got time to read stuff being thrown at them without any engagement ...
Confluence is a proper top-class "Knowledge Management System" which encourages more collaborative efforts. i.e. do you really think that the 10-fold size readership don't have any good ideas or information that everyone could benefit from? You can still lock down a page(s) to only a select few "editors" Using Page edit Restrictions, but I agree with Nic's options. I also think that a dummy User is just that ... dumm! If someone does put in some info to the group you will have no idea who did it ... and nor can they get the reputation for doing so that tends to appeal to everyone's ego as part of the motivation for putting in the effort to do so!.
thanks for your input!
I'm familiar with Content Management Systems, however we would like to have internal and public spaces.
Some of the spaces would be accessible from the outside, some just for specific teams and some should be readable for anyone within the organization.
Of course a cms would be sufficient to just display information, but we are still talking about quite a handful of people that would be editing.
Also this solution would require us to set up a seperate system...
Let me give you one example of what we would need:
We want to build an internal helpdesk with Jira. The internal customers can just be added as customers an Jira and they are allowed to open tickets. However if I want them to be able to find a KB-article, I have to make sure that they have a Confluence-account so that they can use it.
Or I have to make our internal KB public, wich is... Well. Not an option.
Thank you for your explanation.
Sadly I can not reproduce this.
If I have a customer on Jira and the Confluence Space is not set to public, he is not able to see the KB-articles.
I just tired to reproduce this without succcess. Maybe I did not understand correctly?
Thanks a lot!
Do you use templates with Confluence? Take part in a remote 1-hr workshop. You'll receive USD $100 for your time! We're looking for people to participate in a remote 1-hr workshop...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs