In a Category, I have three groups. Members, Moderators and Specialists. The Specialists and Moderators should be able to edit wiki posts. The Members should not be able to edit the wikis as they are not qualified to do so. However, they should be able to reply to a wiki, for example asking for further help.
Currently permissions are as follows:
The problem is, Members can modify the wiki, because the wiki is tied to the reply pemissions. So either replies must be disabled for Members, or need to make all the specialists into Category Moderators so they can edit each others posts, and never use wikis.
I can understand why the permission would be tied to reply rather than create, however:
This relationship is implicit
This relationship causes a conflict of interest ā The group should be able to post a new reply, but not edit the wiki(Where in this case the wiki is the Created post).
Essentially this becomes a backdoor way for users to āCreateā a topic by editing an already created topic.
Possible solution:
I noticed whilst searching that there were a few feature requests along similar lines:
Is it possible to untangle the permission by creating a fourth option āCan edit wikisā?
I worry that adding a fourth āEdit Wikiā permission is a minefield. There is a lot to explain to site moderators about this new toggle.
Adding a security fundamental building block is not a light change, we would be talking probably week or 2 to get this all right, there are tons of touch points.
Does simply amending it so you must have ācreateā permission to edit a wiki in the OP solve your problem?
This may be workable as a change and does not introduce new primitives.
Isnāt this exactly what min_trust_to_edit_wiki Is for? Give reply permissions to all, set min trust to edit to TL3 and make the Specialists and moderators TL3.
I suppose that a Member getting to TL3 is not the biggest threat here (they have something to lose as well)
This change will break how we use wiki. We explicitly want the topic owner to retain ownership so only select groups have ācreateā in a category while topics are wiki by default so anyone who could reply can edit the topic so the info remains correct.
If the permission is changed to create, it will add an overhead to find a different route to achieve this and we probably would have to allow everyone to create topics instead of just reply.
How many of users actually care of TLs at all? Sure, this is strongly related to niche, culture etc. but if/when users get TL3 just because they are active, not because they are trying to reach it, they have nothing to lose.
Active users can behave, most of the time anyway. But because they are active they have tendency to write. And that way they are someway threat here. Factāish is there canāt be too many rules to remember and everything should be as logical as possible. If you have an opportunity, you can use it. If not, thenā¦ well, it is not for you.
Yes, in our case that would work. Essentially this gives the desired tiers of permission within a given Category.
In most cases yes. However the problem is that this is a site wide permission. If I have 5 Categories, and a user is qualified to edit the wikis in one of those categories, they should not be able to edit the wikis in the other four categories.
How frequently are users in the reply category editing wikis? I can completely see the advantage of your approach, but if someone isnāt considered qualified enough to create a topic, then isnāt it a risk when they have the permissions to edit the entirety of the topic which is created? I see this as essentially a permissions backdoor.
In our use case the overhead is actually an advantage. It ensures that the users who are not qualified to edit the wiki, request their changes as a reply, and their desire for modification is discussed publicly. It essentially provides a peer review system for changes to the wiki.
In our case trust levels have been disabled. When using Discourse inside a company, thereās an additional level of liability that needs to be considered. A system that automatically lets someone edit something tomorrow, which they couldnāt edit today, and are not qualified to edit, can cause incorrect information to appear as it were official, causing other people to act upon such information, resulting in faulty products, which results in casualties for customers
But then the solution is clear? Start using TLs, but freeze customers, aka. ordinary john/jane does to some lower level, and give higher TL to them who can edit wikis. Or is there some another reason not to use TLs at all?
If we gave higher TLs to users, they gain this permission for the whole site. This means that a TL3 user from Finance can edit the wiki of an Engineering category. Of course that is unlikely, but the problem is that itās possible.
What is more likely to happen is an Engineer with TL3 who is an expert at Tool A, might edit something about Tool B because they think they are qualified, or simply because they see the edit functionality. Even though there are notifications, there is no guarantee this edit would be detected until after someone else has followed the new, incorrect, information.
A Lot apparently. Generally, the Topic authors are staff (or contract hires) who create various guides & tutorials so theyāre always put into the authors group which has create permission. All the articles are then generally left to the readers with adequate staff moderation to be updated as & when necessary (e.g. certain statements getting obsolete or superseded etc.)
For our case in particular, occasional review by staff has been deterring enough for unqualified users to generally not interfere with any of the wikis. what they rather do is to reply to the topic asking if certain thing has changed. if other fellow members agree of the change, any one of them could make changes to the wiki but if an erroneous change was made by someone, it is generally removed by a staff or another member as soon as they notice it.
Then maaaybe a setting could be added to the admin panel where itās possible to specify whether wiki permissions are tied to Reply or Create? Itās certainly not the most elegant solution, and Iām sure it will be re-visited one day, but for now it bypasses the weeks of effort needed for a fourth permission, allows you(and others) to retain the current functionality which youāre used to, but also provides the alternative functionality that we need on our side.
Definitely not the nicest long term solution, but solves this issue for the forseeable future.
But as you said, there is a level of liability in/on/at (I really, really hate prepositions; canāt you get rid of them ) company level. Corporate environment is totally strange world to me as another minor league player, but you are trying to stop ordinary users to stop editing wikis, right? Inside company it ās only matters of rules ā you (in the mening corporate) will tell who can do what, as usual.
Sure, an option from Discourseās side would be easier. But I can undestand the pain here ā another conditional option and setup will make Discourse much harder to setup, but more versatile to use, thatās true.
That is more or less just edge case on corporate level ā and business model of Discourse lays on corporates, and thatās the reason why you might get that option (unless it costs too much to Discourse, that is another reality too).
But from my point of view TLs would be the fastest way to let wikis out without fear that customers will mess around.
I can be badly wrong too. Such things happends sometimes, not so often, though
In my use case for example I donāt want users spawning more wikiās, I just want them to edit the existing ones without replying to them.
Not really in my case, because I donāt want to give create permission only edit permission.
Really? It sounds very straight forward.
Not really, Iām not going to manually change trust levels of hundreds of users and I actually want new users (starting at trust level 1) to also be able to edit the wiki. The issue isnāt with not wanting them to reply. The graceful way to solve this would be through permissions set per category rather than tie the trust level system into this.
Hopefully the more difficult change will eventually make it through the pipeline though.
I think the title of that setting is very clear, but I donāt think a site setting like that really solves the issue. For me this setting needs to only apply to a certain category, and I donāt want to give those users create topic or reply permission, only edit wiki permission.
We basically are struggling with the same problem. My use case also warrants for having edit permissions in a given category where the topics are only created by a specific group and edit permission needs to be available to everyone who has access to that category but not the permission to create a new topic unless theyāre a part of the specific group.
From the looks of it, a separate permission is the ideal long term solution, but the estimated effort really doesnāt justify the implimentation any time soon.
The suggestion of a site setting which toggles between create and reply would satisfy existing users, but also the request.
This is acheivable with the current permission, and closing the wiki.
I canāt think of a better name, and I would imagine anyone looking for this setting would find this Topic anyway.
) company level. Corporate environment is totally strange world to me as another minor league player, but you are trying to stop ordinary users to stop editing wikis, right? Inside company it ās only matters of rules ā you (in the mening corporate) will tell who can do what, as usual.