Use a View Data Partition to change the Knowledge Category Status visibility.
ExampleOn the SKELETONS Table, put on a View Data Partition Constraint to allow visibility with:
- Draft (status_id=10)
- Publish (status_id=70)
- Retired (status_id=80)
<Please see attached file for image>
Query:(ACTIVE_STATE>=0) AND (READ_PGROUP in @root.pgroups OR READ_PGROUP.[pgroup]contained_roles.role IN @root.role OR (ACTIVE_STATE > 0 AND ASSIGNEE_ID = @root.id) or (ACTIVE_STATE = 0 and OWNER_ID = @root.id)) AND (STATUS_ID=10 or STATUS_ID=70 or STATUS_ID=80)
It is best to align this with the Knowledge Document Visibility assigned earlier to the Role for consistency.
Now when a user of the Knowledge Tab Search or Knowledge Categories Search will show the same list of Knowledge Documents returned.
Caution:
- This query is given "as is." It may be possible to optimise this query further, with further use of the "LIKE" or "IN" operators.
- It may need tailoring to your individual site.
- Please monitor any change to a Data Partition Constraint after implementation to a production system to ensure that excessive SQL query times are not recorded.
- Please see your DBA for all query optimisation as best practice.
Advantages
- Data Partition Constraints are the best practice primary security layer to use
- Data Partition Constraints reduce load on the database by restricting information requests
- Data Partition Constraints apply to all forms of access, such as the web client and pdm_ command line utilities.
Disadvantages
- Data Partition Constraints are "always on." Once restricted, a user is always restricted - unless they change Role.
- You may need to set up multiple Roles for users. A default "restricted" Role, and a "more access" Role.