New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FEATURE: Allow group owners promote more owners #19768
FEATURE: Allow group owners promote more owners #19768
Conversation
app/assets/javascripts/discourse/app/controllers/group-index.js
Outdated
Show resolved
Hide resolved
context "when logged in as a non-owner" do | ||
before { sign_in(user) } | ||
|
||
it "prevents adding of owners with a 403 response" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed from 404 (routing constraint) to 403 (authorization) since this is now in a public controller.
end | ||
end | ||
|
||
context "when logged in as an owner" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test case for the new happy path.
76c3249
to
798ecdd
Compare
put "/groups/#{group.id}/owners.json", params: { | ||
usernames: user.username | ||
} | ||
end.to_not change { group.group_users.count } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im always suspicious of this kind of code without reload it might regress due to some callbacks and we wouldn't get it I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading this again, it wasn't very clear. What I meant: group.group_users.reload.count
and group.group_users.count
could have different output based on callbacks added to models
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting take! I was always a bit suspicious about code that required reload
to test, but I guess we're onto the same thing, just from opposite directions. 🙂 Do you think this should be reloaded in anticipation of future changes, or you think whoever adds a callback later should notice the test failing and address?
@Drenmi is this something you wanted to be merged for 3.0? |
@Drenmi note the backend failures look legit |
798ecdd
to
6ce1808
Compare
Nat confirmed it's for 3.1.
Fixed! 🤞 |
app/assets/javascripts/discourse/app/components/groups-form-interaction-fields.js
Outdated
Show resolved
Hide resolved
@@ -54,6 +54,7 @@ | |||
<BulkGroupMemberDropdown | |||
@bulkSelection={{this.bulkSelection}} | |||
@canAdminGroup={{this.model.can_admin_group}} | |||
@canEditGroup={{this.model.can_edit_group}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having both can_admin_group
and can_edit_group
is a bit confusing, but not related to your change and there is already a comment in the code that explains that can_edit_group
is just for membership changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you. I think the naming exacerbates the problem a bit, as it's not apparent what "edit" and "admin" means. I was actually thinking ahead, how permissions can be structured in a way that one can easily look at it and see what a certain permission can do and not. 🙂
end | ||
end | ||
|
||
group.restore_user_count! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this line do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Managed to dig this out. It's part of Rails dirty-checking. It's a method that's generated here. Why we need that here I still haven't figured out, but I trust it for now. 😬
|
||
users.each do |user| | ||
if !group.users.include?(user) | ||
group.add(user) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be group.add_owner
and then you can drop some of the code around this.
Also, not related to your code, but I hate that we have both add
and add_owner
, when the latter should just be an argument of the first method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the methods, it seems to me #add_owner
should perhaps just be #make_owner
or #promote_owner
. Then we'd have two methods with two distinct responsibilities, whereas right now #add_owner
is overstepping a bit.
6ce1808
to
264cca3
Compare
Thank you for the reviews, @jjaffeux, @nbianca! 🙇 I have addressed your comments with a mix of amendments and topics to revisit some things later. I am weary to change too much of the existing code at the same time as introducing new behaviour. Please re-review and see if you're okay with the current version. 💌 |
264cca3
to
d22a671
Compare
app/assets/javascripts/discourse/app/components/groups-form-interaction-fields.js
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
cc8a15e
to
664cb7e
Compare
664cb7e
to
289d56a
Compare
This pull request has been mentioned on Discourse Meta. There might be relevant details there: https://meta.discourse.org/t/allow-group-owners-to-assign-other-members-as-owners/182227/18 |
What is this feature?
Based on this feature request in Meta. Allows group owners (in addition to admins) to promote other members to owners.
What's not in this PR?
Some of the things mentioned in the Meta thread that I think might warrant their own PRs.
What's the implementation like?
There were two pre-existing permission checks: "can edit group" and "can admin group". The former was used to allow group owners to add new members to the group.
This change makes it so that users with "can edit group" permission (i.e. group owners) can also promote owners.
To make this possible, the
#add_owners
controller action has been migrated from theadmin
namespace (since that is hidden behind a staff constraint) which required just some minor tweaking of the parameters since they were not in line between the two groups controllers.The old test cases still hold, except for non-owners which should now receive 403 instead of 404 (from the routing constraint). In addition there's a test added for the group owner happy path.
Verification
While logged in as a non-admin group owner:
Desktop:
Desktop (bulk):
Mobile: