Planing for internal read-only access and licensing.

[Alexander Schirmer]

Hi folks,
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!
Alex

[Nic Brough -Adaptavist- · Accepted solution]

You have two simple options:

1. An account for each user
2. Anonymous access for reading (no login required)

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.

[Alexander Schirmer]

Hi Nic,

thanks for the lightning-fast reply!

This is what I expected/feared...

I'll put some thought into the option of a dummy user.

Thanks again!

Alex

[Julia Erdel]

Hi Alexander,

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. 

Regards,

Julia 

[Alexander Schirmer]

Hi Julia,

thank you for the idea!

I'll be looking into it.

Alex

[Rodney Hughes]

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!.

[Nic Brough -Adaptavist-]

I did say "read only" dummy user, but we should emphasise that a lot more.  A read-only dummy won't cause you too many problems, but you absolutely cannot let them write (comments or anything)

[Alexander Schirmer]

Hi Rodney,
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.
Alex

[Nic Brough -Adaptavist-]

JIRA Service Desk combined with a Confluence Knowledge base grants customer KB access by default.  Customers are "free" users, they don't consume licences in JIRA or Confluence!

[Alexander Schirmer]

Nic,

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!

Alex