mirror of
https://github.com/discourse/discourse.git
synced 2026-08-07 13:19:19 +08:00
5823e4e3b2Introduces a new way of handling permissions for a target entity within Discourse, including integration with `Guardian` and `User` models. For this initial PR, only group-based permissions will work with this new model, a followup PR will introduce user-based permissions. The initial use case for this is securing Kanban Boards in Discourse Kanban, see https://github.com/discourse/discourse-kanban/pull/58 for the sister PR. In future, we will use this in more places in core, like Chat, Category, etc. The new model is called `AccessControlList`, here is the schema: * `target_id`/`target_type` - Polymorphic columns, can point to any other model * `owner` - A string indicating whether the permission is owned by `core` or a plugin e.g. `discourse-kanban` * `permission` - A free text field, which can be whatever the target requires, but defaults are `edit`, `view`, `manage`, and `own`. `own` at this time is a special permission that should be added to whatever user creates the ACL at first, but should not be shown in any UI * `allowed_group_ids` - An array of group IDs which have this permission * `allowed_user_ids` - An array of group IDs which have this permission A component, called `DAccessControl`, is also introduced to display these permissions and the groups (and soon users) who have them. The component allows a custom description label, and the list of permissions can have their text and description modified, and can also have permissions removed or added as needed for the target: <img width="612" height="222" alt="image" src="https://github.com/user-attachments/assets/88f8d70a-f965-4ef2-9e64-5f8b2bf3fa12" /> <img width="598" height="380" alt="image" src="https://github.com/user-attachments/assets/db90b956-86c2-4ca7-9b63-4c3eb0bad5ef" /> Each target entity can define their own `mandatory_acl` array which is similar to how `mandatory_values` for site settings. For example, Kanban Boards have a mandatory ACL of the admins group ID having the `manage` permission for the board, since admins always need to be able to see + manage boards. This allows us to avoid hardcoding admin/staff escape hatches in guardian/permissions code. These will be shown as disabled rows in the `DAccessControl` component: <img width="577" height="248" alt="image" src="https://github.com/user-attachments/assets/d9bf1754-0530-4edb-b89f-28887cd613d6" /> This commit also introduces a `full_name` calculation for automatic groups, so we can display a nicer version of the name for things like `admins`, `staff`, `trust_level_0` in the UI.
42 lines
1.3 KiB
Ruby
Vendored
42 lines
1.3 KiB
Ruby
Vendored
# frozen_string_literal: true
|
|
module Acl
|
|
class Target
|
|
attr_reader :group_lookup, :permission_lookup
|
|
|
|
def initialize(flattened_acl_list)
|
|
@group_lookup = {}
|
|
@permission_lookup = {}
|
|
|
|
flattened_acl_list.each do |acl|
|
|
@permission_lookup[acl[:permission]] ||= { group_ids: [] }
|
|
|
|
if acl[:type].to_sym == :group
|
|
@group_lookup[acl[:id]] ||= []
|
|
@group_lookup[acl[:id]] << acl[:permission]
|
|
|
|
# TODO (martin) Handle users here too in a followup PR when we allow adding them in the UI.
|
|
@permission_lookup[acl[:permission]][:group_ids] << acl[:id]
|
|
end
|
|
end
|
|
end
|
|
|
|
def group_has_permission?(group_or_id, permission)
|
|
@group_lookup[group_or_id.is_a?(Numeric) ? group_or_id : group_or_id&.id]&.include?(
|
|
permission,
|
|
)
|
|
end
|
|
|
|
def group_has_any_permission?(group_or_id, permissions)
|
|
group_permissions = @group_lookup[group_or_id.is_a?(Numeric) ? group_or_id : group_or_id&.id]
|
|
(group_permissions || []).any? { |permission| permissions.include?(permission) }
|
|
end
|
|
|
|
def permission_group_ids(permission)
|
|
((@permission_lookup[permission] || {}).dig(:group_ids) || []).dup
|
|
end
|
|
|
|
def group_ids_with_any_permission(permissions)
|
|
permissions.flat_map { |permission| permission_group_ids(permission) || [] }.uniq.dup
|
|
end
|
|
end
|
|
end
|
