Add editing permissions condition to view/display Publish Modal

[marcellamaki]

Summary

Description of the change(s) you made

This PR adds a condition based on canManage to determine if Publish Modal is visible.
Fixes #3079

Manual verification steps performed

1. Share a channel as "view only" with a non-admin user
2. Log in as the channel owner/creator in one window, and in an incognito window, also log in as the non-admin user who has "view only" permissions
3. Update and publish the shared channel as the user with editor permissions.
4. Without these changes, the modal should appear in the "view-only" non-admin window, even though the user cannot access/click in to the modal themselves. With the changes, the modal should not appear.

Screenshots (if applicable)

Before

After

Does this introduce any tech-debt items?

Not that I am aware of

---

Reviewer guidance

How can a reviewer test these changes?

Please follow the manual QA process above.

Are there any risky areas that deserve extra testing?

The Progress/Publish modal in general is a bit of a fragile piece of code, so going over more than once manually may be helpful (I have tested this a few times)

Comments

I was curious if this was also a problem with the "syncing" option of the progress modal but wasn't able to reproduce it. If it comes up, I can implement the same change for that portion of the modal as well.

---

Contributor's Checklist

PR process:

• If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
• If this includes an internal dependency change, a link to the diff is provided
• The docs label has been added if this introduces a change that needs to be updated in the user docs?
• If any Python requirements have changed, the updated requirements.txt files also included in this PR
• Opportunities for using Google Analytics here are noted
• Migrations are safe for a large db

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs
• Users' storage used is recalculated properly on any changes to main tree files
• If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[rtibbles]

Looks like the right fix to me!

[codecov]

Codecov Report

Merging #3108 (f6841e4) into unstable (8dd9c1f) will increase coverage by 0.36%.
The diff coverage is n/a.

❗ Current head f6841e4 differs from pull request most recent head 400d36c. Consider uploading reports for the commit 400d36c to get more accurate results

@@             Coverage Diff              @@
##           unstable    #3108      +/-   ##
============================================
+ Coverage     85.76%   86.13%   +0.36%     
============================================
  Files           298      305       +7     
  Lines         15908    16455     +547     
============================================
+ Hits          13643    14173     +530     
- Misses         2265     2282      +17     

Impacted Files	Coverage Δ
contentcuration/contentcuration/utils/user.py	72.72% <0.00%> (-27.28%)	⬇️
contentcuration/contentcuration/tasks_test.py	85.36% <0.00%> (-14.64%)	⬇️
contentcuration/contentcuration/db/models/query.py	94.23% <0.00%> (-5.77%)	⬇️
...ntentcuration/management/commands/exportchannel.py	88.00% <0.00%> (-4.00%)	⬇️
...ontentcuration/contentcuration/utils/pagination.py	81.81% <0.00%> (-2.28%)	⬇️
contentcuration/contentcuration/viewsets/common.py	91.41% <0.00%> (-2.14%)	⬇️
contentcuration/contentcuration/views/nodes.py	61.72% <0.00%> (-2.13%)	⬇️
...uration/contentcuration/tests/test_urlendpoints.py	93.75% <0.00%> (-2.09%)	⬇️
contentcuration/contentcuration/tasks.py	61.58% <0.00%> (-1.68%)	⬇️
contentcuration/contentcuration/celery.py	90.00% <0.00%> (-1.67%)	⬇️
... and 34 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8dd9c1f...400d36c. Read the comment docs.

[pcenov]

Tested and verified as fixed at https://hotfixes.studio.learningequality.org/

[radinamatic]

Having some issues replicating this test scenario 😕

If I'm signed in as one of my Studio non-admin users (A), and I share one of their channels with my Studio admin user (B) choosing view-only permissions, I don't see the View-only label in the upper right corner, and I can still edit and publish that channel when signed in as Studio admin user (B).

Actually, when I open any of the channels in the VIEW-ONLY tab of my Studio admin user (B), none of them have that View-only label in the upper right corner. I can only see the View-only label on channels when I'm signed in as one of my Studio non-admin users. Right now I can't remember if that was always the case, or did something change in this PR...? 🤔

If I'm signed in as one of my Studio non-admin users (A), and I share one of their channels with another of my Studio non-admin users (C) choosing view-only permissions, I don't see any modal opening in the user C window while the user A is publishing a channel view-only-shared with C. Similarly, I don't see any modal opening in the admin user (B) window, while the user A is publishing a channel view-only-shared with B. That was the purpose of the PR, correct?

@marcellamaki hope the above makes sense, as I'm getting 😵 after writing this...

[marcellamaki]

@radinamatic - your description does make sense, but I can't figure out why it is happening -- if this is a new bug, or if there is something else with your admin permissions that would be causing this...I will do a little bit of investigation and see what I find. Thanks for reviewing and for the detailed explanation!

[bjester]

@radinamatic Another change to fix this issue made it such that admin users are always able to edit and publish a channel. So proper replication of this should be with non-admin users only. I'll update the description.

[radinamatic]

@bjester so the current implementation makes the concept of View-only channel meaningless for Studio admin users, correct? Even if they have channels in the VIEW-ONLY tab, none of them will display the View-only label in the upper right corner of the channel edit page?

[bjester]

@radinamatic Yes, channels shown in the view-only tab would never show as view-only when editing as an admin

[radinamatic]

Roger that, we'll need to amend the Gherkin for admin user workflow with view-only channels 👍🏽
cc @pcenov