-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
Thanks for your submission, @openedx/openedx-product-managers will review shortly. |
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. 👍 |
@cassiezamparini @itsjeyd @marcotuts any updates here? |
@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. |
@cassiezamparini nope, how do I find a coordinator? |
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 :) |
@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. |
@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! |
@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 😛 |
@farhaanbukhsh All learning for all of us! And the more you question the better we can make the process :) |
@farhaanbukhsh Noted, will merge once the PR is rebased. |
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! |
@sarina The PR is merged we are good to go here. cc; @cassiezamparini |
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
The text was updated successfully, but these errors were encountered: