KB access permissions

The goal is to make the knowledge base, or parts of it, accessible only to authorized KB users. It assumes that the knowledge base is using its own context in MODX.

Preventing public access

For WLT, this won't be needed, but for other projects it could be a must. So how to create an internal-only KB?

One way is to revoke anonymous view permission from the context itself. That means though, that the login form needs to be placed in a publicly accessible context. The form should then log the user in to the kb context and forward to the start page.

Forwarding login with:

[[!Login?
    &contexts=`hub`
]]

This doesn't seem to fully work. The feature is also labeled "experimental" in the Login docs, so maybe better to avoid that.

https://forums.modx.com/thread/82028/allowing-member-access-to-multiple-contexts https://forums.modx.com/thread/?thread=83395&page=1 https://github.com/opengeek/getCache/issues/5

We'll burn that bridge when we get there. First, let's focus on creating private tickets for WLT.

Restricting public access

The pattern library now has functionality built into the vertical navigation and KB overviews, which checks if user has 'list' permissions. It comes with its own caching mechanism for creating and clearing a custom partition.

Permissions could look something like this:

Anonymous

(website visitors)

• Can only see publicly accessible tickets
• Can't see private tickets, also not in menu and overviews

KB - Members

(WLT users)

• Can only see publicly accessible tickets
• Can comment on existing tickets
• Can create new tickets (save as draft only maybe?)

KB - Collaborators

(Jay)

• Can see all tickets (public and private)
• Can comment and create

Administrator

(Holger, Hugo)

• Can see all tickets
• Can comment and create
• Can use static Markdown files for new tickets
• Can moderate tickets and comments from other users

The KB - Members and KB - Collaborators user groups need to be created still. We can do that in Romanesco Soil already, but that doesn't have Tickets installed by default, meaning access policies are not present yet. So it's either creating an empty User Group (for the sake of the IDs, mostly) or manually adding these groups when implementing a knowledge base.

BTW: users should be considered as content. Meaning: no autoincrement changes to the user group tables either.

In theory, we don't need 2 separate user groups for Members and Collaborators. 1 group with different mimimum roles could already do the trick. The problem is that it becomes way more difficult to check if a user has the correct permissions if you also have to check their role.

For instance: when you currently try to load the correct navigation from cache for a logged in user, the mechanism can only differentiate by User Group:

[[!+modx.user.id:memberof=`[[++romanesco.member_groups_frontend]]`:then=`nav_member`:else=`nav_anonymous`]]`

This would be useful, but doesn't work:

[[!+modx.user.id:userinfo=`role`]]

Copy paste from the docs..

Conclusion: no roles. Bob knows best. Use different user groups for different access levels.

Context settings for KB members

Context settings for KB collaborators

Resource group access for KB collaborators

Creating a private ticket

With the above permissions in place, a private ticket will only be visible to KB members with Super User as minimum role.

This also means that tickets need to be in the KB private resource group. You can do add them to the resource group in 3 ways:

1. Through the Resource Groups tab when editing the ticket itself
2. Under Content > Resource Groups in the top menu
3. By checking the "Private ticket" checkbox in the ticket settings

Option 3 triggers a plugin that adds the resource to the group in the background, so it's essentially the same as option 1.