1

Category and keywords are created at parent publication, there itself we need to assign Write permissions to Author-Groups on Category. Now we don't want the same group to create new keywords in child publications but because of inheritance they can do it.

Now the sad part is even in the Child publication there is no Category Management privilege to this group they can still create new keywords. So if keyword creation is controlled by permissions assigned to group on category then we need to Localize the Category in child publication to make it work, Which we don't want, localization has its own cons to handle.

Any thoughts here for ideal solution in place. (wondering why SDL had not make it as Category and Keyword Management Privilege to keep it simple and easy :( )

Improve this question
1
  • 1
    To be honest, I was also surprised Keywords seem to be allowed solely on (write) permissions. Feel free to submit an enhancement request on SDL Ideas for a new Privilege (or Right) or a ticket as a bug, if you feel it's not quite right. However, I actually wouldn't want more restrictions/flexibility/granularity on Category Management. Personally, I would prefer all Categories and perhaps Embedded Schema were read-only. I'd opt for Jonathan's group idea or similar (I'll leave a comment). Localizing the Category itself should be low impact as well.
    – Alvin Reyes
    Mar 20, 2020 at 20:24

2 Answers 2

Reset to default
2

While, as you say, localisation should be used carefully, localising the category in this case is probably the right thing to do.

If you have a scenario in which localising a category would cause you problems, that's probably best dealt with as a separate question.

Improve this answer
2

You could use Events System code to prevent the members of that group from creating keywords in the lower publication. However, I'd consider this a workaround/hack and agree with Dominic that this should be handled using permissions.

Another option that you may want to consider is using a new group specifically for this purpose and using the scope to control access. For example:

  1. Create a new 'Category Manager' group and give this group 'Write' permissions on the necessary category in the parent publication.
  2. Ensure that the existing 'Authors' group only has 'Read' permissions on the category
  3. Add all of the users that are in the 'Authors' group into this new 'Category Manager' group too. However, you set the scope so that these users are only a member of the 'Category Manager' group in the parent publication (and no others)

Hope this helps!

Improve this answer
2
  • 1
    Good suggestions. You could simplify this further by setting all users to read permissions for all Categories (that'd be my prefer default in the product), and then move the Category Management right into an existing group (e.g. an equivalent tp Chief Editor), scoping these as needed, indeed.
    – Alvin Reyes
    Mar 20, 2020 at 20:29
  • 1
    Yes, I agree about all users having read permissions on all categories but didn’t want to assume that, so went with the Authors continuing to have read permissions. 👍
    – Jonathan Williams
    Mar 20, 2020 at 20:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.