Hi, we need a way to use the knowledgebase for inside information / admin only.
We want to use some of the articles in the knowledgebase without letting our customer (registered or unregistered) to see this internal knowledgebase.
I know there is a way to mark the article as private so only logged in users can view - but we need a way to use some of the articles in the knowledgebase as internal only.
This would be a super useful feature and it should not be hard to implement.
Currently: 1. Categories can be hidden 2. Status can be given to articles
What I suggest is adding an "admin only" status to articles and categories which will reveal them to admin/staff only. This way we can add knowledgebase for our internal requirements.
As an example, we use OnApp and I would like to document certain processes (such as how to restart services when they crash). This needs to be made available to our server admins. Of course we can just keep a google document but it would be a lot simpler if we were able to store the info in the system we all use.
Abivia
commented
10th May 19
Aside from using this for documenting internal processes, it would be nice to use this as a method to keep articles in a "draft" state, so that multiple staff members could review (but not modify) a KB article before it is available to either clients or the public.
This is one flag on the article and a permission in the ACL system. Let me at the source for a few days and I'll have it implemented for you, with docs. :)
Andy Thomas
commented
24th July 18
Would be great as we could add material and videos which employees can refer to if they get stuck trying to doing something. Also would be useful for storing guides/steps to fix or correct certain server issues rather than Googling it. Once a working solution has been found we can add it to our admin knowledgebase for use in the future.
ahmad faizal
commented
17th May 18
+1 for me.. we need this. as there are some KB which are tend for our staff only.
darren
commented
2nd May 18
+1 for internal knowledgebase. I've been researching this feature and essentially i'll have to get another system to for my internal process. and have to remember to add / remove staff to that system as they come and go
Russ Michaels
commented
25th September 17
I got an email saying this topic is declined, which seems crazy.
I am currently using a STAFF WIKI 3rd party addon that is basically just a staff version of the KB. It does the job, but it would better and more intuitive I think to just have it as part of the built in KB, so admins can search all articles from 1 place. It has been suggested to have articles with the option of having them as ADMIN ONLY, but I can tell you from experience using KAYAKO, which does it this way, that there were a lot of times when I found staff had added articles and forgot to set them as "admin only", so they made them public with sensitive info. It would be safer to have INTERNAL categories, so every article in those categories was private by default, rather than mixing private and public articles together. And having them colour coded so it is clear which ones you are editing.
And Private categories should not be available to insert into ticket replies, again for security and safety,
Richard Kinney
commented
14th March 15
the main problem with using the current knowledgebase is that there is no way for admin users to be limited on editing it. In other words, an admin version that has edit restrictions on it would be better. The way it is now, if an admin only article is accessed by anyone who has the ability to manage the knowledgebase then they can edit it. If they dont have that access then they cannot even view the knowledgebase.
Travis Taylor
commented
22nd August 13
I was about to post this same feature request and found ramf had beat me to it.
If you feel that running an internal wiki for staff is a better way to handle this issue, then I could live with that... But having all the data, in one place would be nice. That way if we are looking for answers to customer issues, or our own, we know there is only one place to go. It really does seem like it would be a simple feature to add but I'm not a programmer.
Of note: We are currently running PHPkb because it offers this feature. We'd like to dump it though because it's a real hassle in other area's.
liquid
commented
30th May 13
Another checkbox would make it simple:
"Private Tick this box to make the article private so only logged in users can view"
"Admin Only Tick this box to make the article private so only Admin users can view"
They could be Radio buttons instead, but the second level "Admin" check greying out the "Private" would be intuitive and provide a fallback to be able to make the kb article visible to clients.
Then the search filter for kb articles could have a radio button also for "Admin Only", "Private", "Public". By clicking "Admin Only" and searching for no text, it could show ALL Admin Only articles. (This could also apply to browsing the kb)
ramf
commented
9th May 13
Hi,
Hopefully you are going to implement the rich editors in the ticket system- we are looking forward to it.
but again - let me withdrew my comment regarding the connection between the tickets system and the internal KB.
We need an internal KB to help us spread knowledge to new staff,
to document work regulations and guidelines and so on.
i don't think that the predefined replies is the right tool for it....
Official Response
WHMCS
commented
9th May 13
Maybe giving your upvote for rich editors in the ticket system would be more appropriate so that predefines could contain such formatting as well:
The predefined replies are much more limited, there is no rich text editing and so on.
but - maybe you right,
maybe an admin wiki (not related to the ticket system) is a good idea.
Official Response
WHMCS
commented
9th May 13
Well if your connection is for admins to use it to answer to customers, do predefines not work for you in that regards? With predefines, you can create categories, add links to external knowledge base articles, and they're searchable from the ticket view itself.
ramf
commented
9th May 13
Yes,
But one that is connected to the ticket system so an admin can use it to answer customers.
I think that the easy way to do it is by adding to the knowledgebase system an option to set an articles as internal only just like the "make as private so only logged in users can view " but another option to set it to admin only.
15 Comments
Login to post a comment.
Currently:
1. Categories can be hidden
2. Status can be given to articles
What I suggest is adding an "admin only" status to articles and categories which will reveal them to admin/staff only. This way we can add knowledgebase for our internal requirements.
As an example, we use OnApp and I would like to document certain processes (such as how to restart services when they crash). This needs to be made available to our server admins. Of course we can just keep a google document but it would be a lot simpler if we were able to store the info in the system we all use.
This is one flag on the article and a permission in the ACL system. Let me at the source for a few days and I'll have it implemented for you, with docs. :)
I am currently using a STAFF WIKI 3rd party addon that is basically just a staff version of the KB.
It does the job, but it would better and more intuitive I think to just have it as part of the built in KB, so admins can search all articles from 1 place.
It has been suggested to have articles with the option of having them as ADMIN ONLY, but I can tell you from experience using KAYAKO, which does it this way, that there were a lot of times when I found staff had added articles and forgot to set them as "admin only", so they made them public with sensitive info.
It would be safer to have INTERNAL categories, so every article in those categories was private by default, rather than mixing private and public articles together. And having them colour coded so it is clear which ones you are editing.
And Private categories should not be available to insert into ticket replies, again for security and safety,
If you feel that running an internal wiki for staff is a better way to handle this issue, then I could live with that... But having all the data, in one place would be nice. That way if we are looking for answers to customer issues, or our own, we know there is only one place to go. It really does seem like it would be a simple feature to add but I'm not a programmer.
Of note: We are currently running PHPkb because it offers this feature. We'd like to dump it though because it's a real hassle in other area's.
"Private Tick this box to make the article private so only logged in users can view"
"Admin Only Tick this box to make the article private so only Admin users can view"
They could be Radio buttons instead, but the second level "Admin" check greying out the "Private" would be intuitive and provide a fallback to be able to make the kb article visible to clients.
Then the search filter for kb articles could have a radio button also for "Admin Only", "Private", "Public". By clicking "Admin Only" and searching for no text, it could show ALL Admin Only articles. (This could also apply to browsing the kb)
Hopefully you are going to implement the rich editors in the ticket system- we are looking forward to it.
but again - let me withdrew my comment regarding the connection between the tickets system and the internal KB.
We need an internal KB to help us spread knowledge to new staff,
to document work regulations and guidelines and so on.
i don't think that the predefined replies is the right tool for it....
http://requests.whmcs.com/responses/enable-tinymce-editor-for-tickets-as-well-as-auto-save-functionality
but - maybe you right,
maybe an admin wiki (not related to the ticket system) is a good idea.
But one that is connected to the ticket system so an admin can use it to answer customers.
I think that the easy way to do it is by adding to the knowledgebase system an option to set an articles as internal only just like the "make as private so only logged in users can view " but another option to set it to admin only.