Description of problem: When uploading a manifest in an Org, and then switching to another org to do the same, user is greeted with the manifest upload status bar from the previous org. Version-Release number of selected component (if applicable): 6.4.0 snap 10 How reproducible: Steps to Reproduce: 1. Create two orgs, "Org ABC" and "Org 123" 2. Switch to Org ABC 3. Content > Subscriptions > Manage Manifest 4. Upload Manifest; observe the expected status bar UI 5. While manifest is uploading, switch to Org 123 6. Content > Subscriptions > Manage Manifest Actual results: The "Uploading %" status UI from the first org appears on the page of the second org. Expected results: There should be no evidence of what's going on in one org, in a separate one. Org manifest handling should be wholly independent and opaque across orgs. Additional info:
FWIW this occurs during a manifest refresh as well. 1. refresh manifest in one org 2. switch org and go to subs page. Second org sees the manifest refreshing (vs. uploading).
Created redmine issue https://projects.theforeman.org/issues/24126 from this bug
One potential fix would be to add context for the notification. That way a user with multi-org access can still get notifications, but know the proper context. "Manifest successfully uploaded in Organization Org123."
Upstream bug assigned to afeferku
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24126 has been resolved.
Amir, This failed cherrypick downstream. Can you take a look?
Hello Patrick, I was looking into this BZ for cherry-pick and found that there 8 extra commits that needs to be cherry-pick with this change. It may or may not introduce high risk by cherry-picking multiple commits. And for each commit we need to check if any BZ present so that we can mark them as blocker with sat 6.4 flag. Please check below commit ids for reference: 1. Fixes #24324 - Update eslint commands and fix issues git cherry-pick -x 2f5e99ff6329f7f0fbda715196bd6e89d64c1c98 2. Fixes #23510 - available quantities errors don't block editing git cherry-pick -x c528389076d19fee443f9dcfa2b85ed3db12874f 3. Fixes #24336 - upgrade jest and fix errors git cherry-pick -x 63746060ec97dfbfea0908e922a98fbe13d32db8 4. Fixes #24423 - fix jest errors git cherry-pick -x c37ea4a53a492c04e849a208977e178923627b8c 5. Fixes #24597 - Exit properly for eslint git cherry-pick -x f5322438f94ad87a475a9cacb0610dff44fdebcc 6. Fixes #24283 - remove pf bindMethods function git cherry-pick -x d23e07c5822cd60b7d1790f76fefd49fce4a6253 7. Fixes #22733 - Add customizable columns to Subscriptions Page git cherry-pick -x f1c81f012e86477fc0b49e732c70c0ef65e45e4a 8. Fixes #24996 - eslint errors git cherry-pick -x 9bd6dc8ae110565120a7fd5eb5332d7f86bd5de8 9. Fixes #24126 - fix manifest tasks from bleeding to other orgs i.e BZ-1596885 git cherry-pick -x dc7b4c78a05c7bda35f0b3496e2da5423b904091 Please confirm about these changes for merge request. Once I get confirmation I need to check if there is any BZ for each of them.
From the e-mail on this, from walden on the above comment: "We should probably continue this discussion in the bugzilla but given the above I would vote that we move this out of 6.4 as it will introduce a good amount of risk." Asking mmccune for input
This is too risky to pull into the GA, will continue to work on it but it will need to be moved to a later release.
Hello This bug is fixed but a second user cannot load a manifest at the same time and now there is no indication that another manifest is in the process of being uploaded. I opened: Bug 1649703 - Simultaneous manifest upload by two users fails Thank you
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:1222