Title: Adjust the description text of two options for better understanding - knowledge base reader / editor
Usecase environment:
average concurrent agent count? 5
average tickets a day? 20
what roles/people are involved? Customer / Agents
The description of two options are in my opinion misleading. These options descriptions are the descriptions for knowledge_base editor and reader:
For a better understanding the two descriptions should be rephrased. In the current form they could also be read as if the user can then edit / manage other editors / readers.
describe what is the problem you like to solve?
Make the description clearer for everybody / admins - The description is unclear if it may lead to more rights for the affected user group / role.
describe one or two concrete situations where this problem hurts the most
We had the problem that we donât want to put sensitive information on the internet via our Zammad knowledge base. So we looked for another solution and found these two options. The description of these options were unclear to us. We wanted only to allow ânormalâ users to access the knowledge base without being able to âmanageâ other users as the description may have hinted.
why is it not solvable with the Zammad standard?
We canât edit the description by ourself or edit it in a persistent way.
Help us understand:
describe WHAT is your expectation / WHAT do you want to achieve?
Rephrase these two descriptions. Rephrasing them to âGrant read access to internal knowledge base answersâ and âGrant write access to internal knowledge base answersâ would make the description more understandable.
If there is any more useful information, feel free to share it all (e.g.: Mockup screenshots, if something is UI related or the API URL / Documentation URL for a service you need a connection to):
Usecase environment:
average concurrent agent count? 10
average tickets a day? 20 and up
what roles/people are involved? Customer, Agent, Admin
everything else which you think is useful to understand your use case? no
Thank you for bringing this up! Please use the provided template properly, it will help us understand your need better and also provide us necessary information to consider your idea. Thanks!
I donât know if this will help to make the thread more clear but here a new try with the template:
Title: Adjust the description text of two options for better understanding - knowledge base reader / editor
The description of two options are in my opinion misleading. These options descriptions are the descriptions for knowledge_base editor and reader:
For a better understanding the two descriptions should be rephrased. In the current form they could also be read as if the user can then edit / manage other editors / readers.
describe what is the problem you like to solve?
Make the description clearer for everybody / admins - The description is unclear if it may lead to more rights for the affected user group / role.
describe one or two concrete situations where this problem hurts the most
We had the problem that we donât want to put sensitive information on the internet via our Zammad knowledge base. So we looked for another solution and found these two options. The description of these options were unclear to us. We wanted only to allow ânormalâ users to access the knowledge base without being able to âmanageâ other users as the description may have hinted.
why is it not solvable with the Zammad standard?
We canât edit the description by ourself or edit it in a persistent way.
Help us understand:
describe WHAT is your expectation / WHAT do you want to achieve?
Rephrase these two descriptions. Rephrasing them to âGrant read access to internal knowledge base answersâ and âGrant write access to internal knowledge base answersâ would make the description more understandable.
If there is any more useful information, feel free to share it all (e.g.: Mockup screenshots, if something is UI related or the API URL / Documentation URL for a service you need a connection to):
Usecase environment:
average concurrent agent count? 10
average tickets a day? 20 and up
what roles/people are involved? Customer, Agent, Admin
everything else which you think is useful to understand your use case? no