Ownership groups & creating articles in shared KB without ability to edit other groups' articles

[jasonkohl]

We would like to configure a central end-user facing knowledge base where multiple ownership groups can manage the lifecycle of their knowledge articles (create, edit, retire, process feedback). We gave the ownership groups Can Contribute access to the KB which allowed them to create new articles, but it also gave them the ability to edit different ownership group articles which we did not want.

If we removed the ownership groups' Can Contribute permissions from the knowledge base, the ownership groups could edit their assigned articles but did not have the ability to create a new article in the KB.

How can we configure the single shared knowledge base so that different ownership groups can create new knowledge in it but then only be able to edit articles assigned to their group?

[jasonkohl]

Thanks Shannon, here is some additional clarity.

- We have a user-facing knowledge base where end-users can see the content.

- We want specific knowledge ownership groups to be able to create new knowledge articles within that knowledge base, but we only want them to be able to edit their own articles. Right now, it seems they are able to edit other ownership groups' articles.

Configuration we've tried:

- We have added the different ownership groups into a user criteria group, and then provided that user criteria group 'Can Contribute' access to the knowledge base.

- The different ownership groups are able to create new knowledge articles within the KB and assign them to their ownership group.

- Even if an article is assigned to ownership group A, individuals from ownership group B are still able to edit it. We only want individuals from the assigned ownership group to be able to edit those articles.

If we remove the user criteria from 'Can Contribute', then the ownerships are only able to edit their own articles, but they are not able to create new knowledge articles within that knowledge base.

[shannont]

Hi @jasonkohl ,

You may have already tested this but maybe its the UC groups you've created using the OGs? Have you tried using a different filter to bring in the Users you want to have Can Contribute access vs using the OGs in the UCs? That might be a good test as we don't use our OGs for our UCs at the KB level (love all the acros LOL).

[jasonkohl]

That is a good thought, we'll try this out.

[Peter102]

We are on Washington DC Patch 6. 

We have all itil users as Can Contribute 

All users as Can read.

This is on our IT knowledge base.

We have enabled ownership groups on each KBA and they are the only ones who can edit individual articles that they own.

Looking at the description of Ownership groups in the SNOW documentation, what you are trying to do, should be how ownership groups are meant to work and it is how it works for us.

I will be honest, what you have described, sounds like you are trying to use groups to manage access without enabling the ownership group setting (see above link).

I could be wrong, ours has been setup for quite a while so there may be some customization that I am unaware of but I dont think so as the descriptions in the article match it.

Otherwise, I'm missing something here.

[jasonkohl]

Thanks Peter, we're scratching our heads on this one, too. I had our development team double check the setting, glide.knowman.ownership_group.enabled, and it is enabled in all of our instances.

We have created a user criteria group that has Can Contribute access to the knowledge base, and then we added the individual ownership groups to that user criteria group. I don't see why it would matter, but I'm curious if we add each ownership group to their own user criteria group and then add those to Can Contribute on the knowledge base.