So,
We actually have solved this issue now.
It turns out that the affected Forum was set to only have Keymaster in “Ultimate Member” Permissions!
So we’ve now rectified that and everything is working as it should do.
However the only discrepancy is that when we created test participant accounts that did not have the “Keymaster” permissions, we were able to reply, as could another end user account that had only “participant” permissions.
So in short, we’ve solved the issue but there appears to be a bit of strange grey area here where some users can still reply despite not having the permissions to.
Ok, so because we’ve not been able to replicate the issue with test accounts et al. We think that if we delete the end user’s account and then remake the account this will rectify the issue. As we’re aware that the user may already have content that they’ve created under their account we want to migrate that to a dummy account while we’re putting in place the deletion so we can then migrate it back to their “new” account and thus cause little to no disruption for them. We just wanted to check that if bbpress content is in this equation, that this content type does also get re-allocated like any other WP content types.
So we’ve done some digging around on the forum and found an instance where someone had the same issue? https://bbpress.org/forums/topic/participants-cant-create-topicspost-replies/
and they then say: ‘Found it – buddypress was applying a filter, and it does some wonky logic. Overwrote it in my theme.’
Would the you guys know what we could do to force override this to ensure all participants can reply to solve this?
We have not been able to replicate the error so it appears to be only for this one topic, and only these users.
Users have provided us with screenshots showing that the text box to reply and submit button are not present.
This has happened for two separate users on different machines and they have tested other browsers, clear caches and in standard browser modes and incognito / private browsing modes.
A temporary solve was managed by changing their permissions from subscriber (whitelisted) to keymaster and they were able to reply to the thread. However in our testing we haven’t been able to establish the reason why these particular users were not able to reply as all test accounts were able to reply with subscriber (whitelisted) permissions.
We aren’t able to log in and test the end user accounts as they are public sector organisations using SSO.
