Discourse의 많은 기능이 신뢰 수준(trust level)에 기반하여 액세스 권한을 부여하는 설정을 사용합니다. 하지만 수년간 이 방식이 너무 비유연하다는 점이 입증되어, 이제 특정 그룹의 멤버에게 액세스 권한을 부여하는 새로운 방식으로 전환하고 있습니다.
신뢰 수준에 의존하는 기존 설정들을 이제 그룹에 의존하도록 전환하기 시작합니다. 아래에서 전환을 목표로 하는 설정 목록을 확인하세요. 일부 설정은 신뢰 수준 기반이 유지되는 것이 합리적일 수 있습니다. 작업을 진행하면서 목록을 업데이트하고 여기에 댓글을 추가하겠습니다. 누락된 설정이 있거나 문제를 발견하신 경우 알려주세요!
기존 방식의 대표적인 예는 shared drafts min trust level(공유 초안 최소 신뢰 수준) 설정입니다. 이 방식을 사용하면 신뢰 수준 4 또는 모더레이터 권한을 부여하지 않고 특정 사용자에게만 액세스 권한을 부여하는 것이 불가능합니다.
새로운 방식의 예로는 whispers allowed groups(속삭이기로 허용된 그룹), personal message enabled groups(개인 메시지 활성화된 그룹), hidden post visible groups(숨겨진 게시글 표시 그룹) 설정이 있습니다. 기본 그룹 외에도 제가 만든 그룹(access_oskar 및 kabissastories)에 액세스 권한을 부여할 수 있음을 확인하실 수 있습니다.
This is just awesome! Amazing! I’m so excited about this.
Discourse has been granting some additional permissions at trust level 4, such as global pin/unpin topics, close/open topics, can these also be modified to some specific groups?
TL4 may be carrying too much. Sometimes for some relatively large communities, some fine-grained permission control may be needed. For example, a group may be needed, in which people can always review and edit everyone’s posts in all categories, but they should not be able to pin topics globally.
If it could, the discourse would become highly customizable, which I think would make the whole thing awesome!
If it will be added to the roadmap in the future, I don’t know if I may help?
Now with what appears to be set based or relation based, perhaps not even a static visual will do but an interactive page.
I would post an example of such an interactive page, as the one I have in mind is nice, but saw it a few years back and don’t recall the site or details of how to find it.
It would be similar to one of the Cytoscape.js demos.
No, this has nothing to do with how people are added to groups or the trust level system. It just expands settings for giving access to features by allowing one or more groups to be added, not just trust levels.
Not sure what you mean here but again not related to this topic. I’d suggest starting a new topic to explain in more detail what it is you are wanting to do. Many things are possible in Discourse.
Not sure what you mean here either and probably not in scope for this topic.
This is an interesting out of the box thought.. with this new direction trust levels beyond TL3 potentially become less relevant. TL4 is already only achievable by an admin giving it to a user, so it could be replaced with just creating groups for different roles in the community, giving those groups the appropriate permissions, and then adding people to those groups.
I have no idea what you are referring to - if you could share an example and explain it, I’d appreciate that.
Perhaps dating myself, but my mind goes to Drupal roles which had a fairly horrifying table-based UI for visualizing and configuring roles and permissions. I wouldn’t want to go back to that but perhaps somebody could do a data explorer query to create a table view of groups and their permissions.
We also already have a PERMISSIONS tab on groups pages, which indicates which categories members of the group have access to. Perhaps we could expand on this to also show what features the group has access to.
After seeing your response to N2U it seems that (from trust levels to groups) is not what I thought.
I was thinking that this was going to move all trust levels into groups then remove the concept of trust level and start to only use group for privileges. As I now know that is wrong will have to see where this leads as it is not what I was hoping.
Trust levels are not going anywhere, and the trust level system remains an important part of Discourse.
I guess where this becomes a bit confusing is that trust levels are also groups!
What we are now doing is changing some admin settings so they don’t just let you decide the trust level to give access to given features but to let you specify one or more groups. By default these will still be the trust level groups as before but you can now change this to any group or groups as appropriate for your community.
I think in general and the more with this new direction, the workings of trust levels could be easier to understand and communicate making this more evident. And having a conceptually clearer distinction to badges and their more playful side to gamification.
E.g. right now trust levels show as badges, though the access rights actually come from group membership. But those groups don’t show by default. Trust levels could be removed from the badge system and the badge page and only show on the groups page (with natural names instead of trust_level_x).
I’m curious how do you (the team) explain the distinction between trust levels and groups conceptually. Put in a different way, I wonder if you say this simply because trust levels have been in Discourse for so long that they feel innate and as something untouchable.
With these updates, what makes trust levels special? That the membership in them is rule-based and updated automatically? But if so, what stops you in the future from allowing users to create rules for automatic addition to manually created groups?
I don’t have a problem with these updates, I guess I’m just curious what’s your vision
Thanks for bringing this up. As I wrote above, trust levels aren’t going anywhere and the trust level system is important. It provides sane defaults that any community can be happy with, and Trust levels actually are special. You cannot delete trust level groups, and there are settings that allow you to tweak how your members move between trust levels.
But if you need more flexibility in terms of the privileges you give people in your community you can now specify additional groups for many of settings that you create and manage. This way you have even more granular control.
It’s true that now that we have moved so many of these settings to this new approach the “Trust Levels” category of the admin settings feels a little weird, because you can now remove trust level groups from many of the settings in there. See screenshot below for what I mean.
We’re working on improving the structure/organization of the admin section as well, so will take this into account.
So I guess we’ll have two conceptually distinct categories?
One for system trust levels and tweaking the conditions that grant trust levels. That are all the settings as this one:
Another for adjusting access rights based on groups. That is all the settings like this:
I’d like a separation like this for two reasons:
Tweaking the system trust level conditions in a meaningful way is difficult. You face a long list of number-based settings like tl_x requires...this number of this action… If all these are in one distinct category it’s easier to explain that these are the default trust system settings. You could tweak them, but you can also just leave them as they are.
Instead you built your custom trust scheme with your own groups. And when conditions for system trust levels are all grouped in one place it’s easier to build your own group conditions with a distinct mental concept.
For example one concept I’ve been playing with because it’s more visual is just using badges for member levels. Levels are granted by x number of badges a member is awarded from the respective badge group:
This could belong somewhere else, but I really like using groups to limit or give rights. Sure, if used something else than automatic groups of trust levels it can be quite big mess quite fast, but it is only matter of planning and documentation — admin should describe why a group is there, because no one remembers after some months why something is done in the first place
Hi there, great news about a fine granular access control over groups.
Just some additional question about category moderator groups.
A concrete example, a category moderation group shall be able to edit a post. Basically re-categorizing it only within their categories and sub categories where they are assigned moderators, is this also considered?
What’s about the moderator role will this also be integrated in the groups?
We are not touching category moderation specifically as part of the changes discussed in this topic - we are only changing the settings that are listed in the first post above.
To join discussions around category moderators and to suggest improvements, take a look at the category-moderators tag.
