Comments visible at a particular access level: is it possible?

[danpdanp]

Hello,
I don't think it is possible, in Akeeba Engage, to make it so that whoever posts a comment can make it visible only to a specific access level, as defined by the Joomla ACL.
And I think it is not even possible to "suspend" comments for a specific article, pending the evaluation of an administrator.
If, on the other hand, one of these functions is already present in the component ... I ask for help with its configuration.
Thank you
Regards

[nikosdion]

I don't think it is possible, in Akeeba Engage, to make it so that whoever posts a comment can make it visible only to a specific access level, as defined by the Joomla ACL.

Correct, that is not possible. Comments follow the same access level as the article itself. This is not something I am going to change for performance and complexity reasons — mostly performance, to be honest, especially if you have articles with more than a couple dozen comments.

And I think it is not even possible to "suspend" comments for a specific article, pending the evaluation of an administrator.

You have to think backwards. Have the default (in Engage's Options page or the category's configuration page) to be that comments are disabled on articles. When the admin reviews the article they can enable comments for that specific article.

[danpdanp]

Thanks for the reply. In my blog, in general, all users of a specific group (with a specific level of access) must be able to write comments on the articles of a certain category, which (comments) must be published immediately, without the approval of the administrator. So I configured the component to achieve this. For a single article (only one) I needed that comments could be written by all users but visible only by the administrator, before their publication. This is why I asked if it was possible ... Regards!

[nikosdion]

That's an interesting use case. As things are right now I can tell you that it's not possible. However, I'd like to take some time — well, when I actually have the chance — to pursue this. Maybe I could make the option to decide what to do with new comments (published or unpublished) an inheritable option, meaning that each category or article could override the global setting. Off the top of my head I think it's possible but I really do need to find a couple of hours to properly pursue this and make sure that what I have in mind can be turned into code.

[danpdanp]

Thank you so much!
Akeeba engage is already a great component. That feature would make it even better.
Regards!

[nikosdion]

Good news! It is possible and I implemented it. I will make a new release next week, Akeeba Engage 3.1.0 for Joomla 4, which will include the new feature.

[danpdanp]

Great news! Thanks again!

[ericsps]

Hello,
I found this thread and wanted to provide a use case and see if this is appropriate for this discussion:

Use Case:
Article 1- View Level "Registered", Category "Podcast 1", Moderators "Group 1"

Article 2- View Level "Registered, Category "Podcast 2", Moderators "Group 2"

Currently, I don't see an option to set permissions at the category level, It seems that permissions are only set at the component level. Is is a correct assumption? If so, will this new release going to include this feature?

Thanks in advance for your consideration!

[nikosdion]

You can’t set custom Permissions per category and article beyond what Joomla already provides. Doing so would require to modify Joomla’s com_content and com_categories. So, the answer to your question is “never, unless Joomla implements a feature to extend permissions of categories and articles which sounds extremely unlikely”.

[ericsps]

Nicholas,
Thanks as always for the response and providing such great software!

[nikosdion]

You're welcome! I wish I had a better reply. Your use case is something I had thought of when I first wrote Engage in 2020. I had spent two days trying to solve it with no luck. Whenever I have some time I will give it another go. I have another two things I might want to try but neither is a guaranteed success.

[rinenweb]

Hello, I would like to ask since "Comments follow the same access level as the article itself", would it be logical for comments made in an article with "Registered" access level, to be publicly visible? Because I 've just stumbled upon this case using Akeeba Engage 3.2.3 on Joomla 4.2.6. Is that supposed to happen?
Nevertheless, the truth is that a "view comments" permission would be a great addition in the component's Permissions tab.

[nikosdion]

If Joomla, or rather your template, is calling the display events in this case then it is a bug in Joomla. From the plugin's point of view —where it is only given an article object, a context, and told to render itself— there is no way to discern if Joomla is rendering the article in full or just partially.

As a matter of fact, Joomla (or, rather, YOUR TEMPLATE), MUST NOT output the plugin-generated content in this case because it can be reasonably expected to contain information related to the article, the same article which is not being displayed in its entirety because of access level.

Therefore —and I cannot stress this enough— the problem DOES NOT lie with Akeeba Engage.

[rinenweb]

For the record it's Cassiopeia, the default Joomla template... but I see your point.

[nikosdion]

Unfortunately, Joomla is not so much designed as a whole as it is haphazardly slapped together by people who can't see the whole picture, with PRs which are perfunctorily reviewed by any two random GitHub handles. There is no code review by anyone who understands Joomla and security. That's how we get crap like this.

I've been speaking against this insanity since 2009. Nobody listens to me. I am labelled as “difficult to work with”. Well, duh, I am VERY difficult to work with if the person I am called to work with has a work ethic that spans the range between ‘I have zero responsibility bEcAuSe I aM a VoLuNtEeR‘ and ‘YOLO!‘. I have very stringent work ethic standards. I am a Mechanical Engineer, it's been etched into my very existence during those five years at uni that I am responsible for my work and the well-being of the people using it. If I got 99% of the way into solving a problem but the end result would have gotten someone killed because I cocked up a “small detail” I would get a big, fat 0 in my project's grading form (to drive the point home that had this been real life, the chance of me staying out of prison for third degree murder would be exactly zero, ahem).

For this issue in particular, it's very simple to see how the “Show Unauthorised Links” feature patently fails to maintain privacy and security. The \Joomla\Component\Content\Site\View\Article\HtmlView class checks if unauthorised links are allowed in line 179. Lines 210 to 261 simply empty the article's full text. Then lines 225 to 237 run the content plugins regardless of the access check, and without passing the results of the access check at all. 🤦🏽‍♂️ Therefore any content plugin including Joomla's Fields (custom fields) will happily execute, return results, and the view template will happily display them to everyone and their dog. YOLO!

My recommendation for now is to not use “Show unauthorised links”. This feature was written in a way that can only be used on sites which use absolutely no content plugins, not even Joomla's custom fields. Using it will result in pain and suffering.

I am not sure if I can work around it, but I'll try. I have a few ideas.

[rinenweb]

Happy new year!
In the end, my idea for a workaround was to set the "Content – Akeeba Engage" plugin to Registered Access Level. I know it's far from ideal, since all functions of Engage component essentially disappear from Public view, but it quaintly works fine in this particular case/project. :)

[nikosdion]

Happy New Year!

Yes, it's not an ideal solution as it means that only people in the Registered user group will be able to see comments, submit comments, and manage comments. Essentially it removes any kind of public comment feature and frontend comments management (since all privileged users are not members of the Registered user group which is the only used group included in the Registered access level).

I am going to make a new release tomorrow which assesses the article's access before rendering comments and the comment count. It's slightly ass backwards having to do that in the content plugin but, hey, if Joomla won't do it right we can at least work around it!