WikiGuest not seeing RenderCategoryTiles or RenderCategory

Really stumped... WikiGuest can't see any content in "...Category" topics. Just shows with a blank body. I've checked the ClassificationApp permissions, and that of the web. Also manually used %DBCALL rather than the preference based default, and still doesn't work. Is this something to do with DBCALL? I've locked down WikiGuest functionality, but not that significantly!

-- JonMcCoy - 09 Mar 2024

I've managed to resolve this, so documenting the cause/resolution for future reference:

I expanded out to looking at ACL/auth preferences. Being a public facing wiki, I had {AccessControl} set to Foswiki::Access::TopicACLReadOnlyAccess. When looking at the list of ACL options, I noticed a new one had appeared after installing ClassificationPlugin - "Foswiki::Access::ClassificationACLAccess" which got me thinking that it could be the ACL... back to that in a minute.

I reverted back to the default Foswiki::Access::TopicACLAccess, and the category rendering immediately started working. It would appear that Foswiki::Access::TopicACLReadOnlyAccess restricts one or more of the MACROs used by ClassificationPlugin to display CategoryTopic.

Luckily AFAIK, my web preferences are already setup right, and I have every script minus view, viewfile, ooops, search and FCGI set to require auth, so its all fine. I've not looked into any code, but clearly one of the called MACRO requires write access, or is incorrectly authorising using change vs view. I don't know which MACRO, but DBCALL and INCLUDE work, so I have to assume it's something else called from the RenderCategoryTiles or RenderCategory functions.

Back to the "Foswiki::Access::ClassificationACLAccess", reviewing the code it looks like it inherits Foswiki::Access::TopicACLAccess and overlays additional ACL applied to the Category structure. I've not tested yet and unable to find any docs, so unsure 100% as to how it works, but could be very useful!

-- JonMcCoy - 11 Mar 2024

ClassificationACLAccess has not been fully implemented. Consider it alpha. It most probably is going to be removed in future releases.

-- MichaelDaum - 11 Mar 2024

Thanks Michael,

I didn't want to test it on the public facing install, so was going to try it on an in-house one instead.

Depending on how it works, I could see it being very useful for projects. Being able to lock down categories and associated content is a powerful option...

Am I correct in thinking it doesn't recurse, so it only look's at the assigned category, and doesn't inherit permissions from parent categories?

Also what happens if a topic has multiple categories assigned to it?

Thanks

-- JonMcCoy - 11 Mar 2024

Bringing together categories and acls is some sort of nightmare, a tool to heavily shoot your own toes for the reasons you mentioned: recursion, contradicting rights coming from different branches of the category tree etc.

The main selling point for webs compared to categories is access rights. If there are a bunch of topics that need special protection compared to the rest, then create a separate web for them. This is proven tech and best practice.

Category-based acls have been requested multiple times and I always talked people out of the idea given that webs are there to be used for exatly that use case.

-- MichaelDaum - 11 Mar 2024