Skip to content
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

[Pull Request]: Remove "Add a post" button when discussion is restricted for specific roles #391

Closed
farhaanbukhsh opened this issue Nov 6, 2024 · 13 comments

Comments

@farhaanbukhsh
Copy link
Member

farhaanbukhsh commented Nov 6, 2024

Abstract

The issues we faced were when the discussions were restricted the "Add a post" button was shown to global staff and superusers but when they create a post the MFE doesn't let them create the post and the backend raises a 403 error.

Detailed Product Proposal

No response

Context & Background (in brief, if a Product Proposal is linked above)

The issues we faced were when the discussions were restricted the "Add a post" button was shown to global staff and superusers but when they create a post the MFE doesn't let them create the post and the backend raises a 403 error.

This happens because there exists a mismatch in permission on who can create a post when discussion is restricted.

There is a mismatch in the roles, hence I am taking edx-platform as my source of truth and what the implementation should be hence I dug a little deeper. From edx-platform we can confirm that only the user who has one of the following roles Discussion Admin, Moderator, Community TA or Group Moderator are allowed to make the post even during the restriction period. The proof for this is:

Docstring for has_discussion_privileges

This proves that course staff doesn't have priviledge

The MFE uses api at <LMS_URL>/api/discussion/v2/courses/<COURSE_ID>/ which uses get_course and here if the user has has_moderation_privileges or is_group_ta then they can post on a restricted discussion.

Hence on the MFE we need to change isPriviledge to use:

userHasModerationPrivileges || isUserGroupTA

and we should be aligned with the original idea.

Scope & Approach (in brief, if a Product Proposal is linked above)

This is a fix led by OpenCraft since the behavior already existed in the Legacy UI but they were missing in MFE.

Value & Impact (in brief, if a Product Proposal is linked above)

This brings the permission in the edx-platform inline with the usage in MFE.

Milestones and/or Epics

PR: openedx/frontend-app-discussions#742

Named Release

Teak

Timeline (in brief, if a Product Proposal is linked above)

It is ready to merge.

Proposed By

OpenCraft

Additional Info

No response

Copy link

github-actions bot commented Nov 6, 2024

Thanks for your submission, @openedx/openedx-product-managers will review shortly.

@marcotuts
Copy link

I'm not sure if what the legacy experience has is ideal, having previously run into issues / bug reports here only to realize that for that given course the permissions were missing for discussions specific roles, but that's a topic for another day. :) Perhaps in the future we could decide that superusers / course admins should automatically inherit discussion moderation and other needs, otherwise you have course operators / admins unsure of why they can't do basic discussions operations. This is all a low incidence / frequency thing so I don't think this is a rush to consider but for future RBAC work perhaps.

Matching the behavior as you described above makes sense, +1 to merge IMO. 👍

@farhaanbukhsh
Copy link
Member Author

@cassiezamparini @itsjeyd @marcotuts any updates here?

@cassiezamparini
Copy link

@farhaanbukhsh Correct me if I'm wrong - but has this proposal had a coordinator assigned to it? That way the coordinator can push for feedback.

@farhaanbukhsh
Copy link
Member Author

@cassiezamparini nope, how do I find a coordinator?

@cassiezamparini
Copy link

See the process here. So you can also be the coordinator - see Step 1 "d". Maybe that's best.

Then see Step 2 of the process if you'd like to take the role on :)

@farhaanbukhsh
Copy link
Member Author

@cassiezamparini I think I can do it :) so there are no objections here or this needs to be discussed more? Since @xitij2000 who is a CC for the repo has already approved it.

@cassiezamparini
Copy link

@farhaanbukhsh It looks like it may be good to go seen as you've had one +1 from an external organization as well. This is a bit of a grey area right now... how many reviewers are enough 😆 If you'd feel more comfortable having more reviews, you can always ping people directly on Github.

If you go ahead, I would just update the statuses accordingly and add it to the community release sheet when you get there 😄 And also please let me know if you have any queries about the Product Process! Always wanting to improve it!

@farhaanbukhsh
Copy link
Member Author

@cassiezamparini okay, so I will just ask @xitij2000 that the PR is ready for merge :)

I do need to spend a bit more time to understand the Product Process I seem to be pinging people cluelessly which shouldn't be the case 😛

@cassiezamparini
Copy link

@farhaanbukhsh All learning for all of us! And the more you question the better we can make the process :)

@xitij2000
Copy link

@farhaanbukhsh Noted, will merge once the PR is rebased.

@sarina
Copy link
Contributor

sarina commented Nov 19, 2024

I signed up to coordinate this, it seems good to me and has +1's from a varying group. I think this is good to merge!

@farhaanbukhsh
Copy link
Member Author

@sarina The PR is merged we are good to go here. cc; @cassiezamparini

@sarina sarina closed this as completed Nov 25, 2024
@github-project-automation github-project-automation bot moved this from [Prod Proposals] NEW to Abandoned in Open edX Roadmap Nov 25, 2024
@sarina sarina moved this from Abandoned to Shipped in Open edX Roadmap Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Shipped
Development

No branches or pull requests

5 participants