Bug 1596885 - Manifest upload UI status bleeds into other orgs
Summary: Manifest upload UI status bleeds into other orgs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Subscription Management
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
high vote
Target Milestone: Released
Assignee: Amir
QA Contact: Stephen Wadeley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-06-29 23:05 UTC by Corey Welton
Modified: 2019-10-07 17:13 UTC (History)
6 users (show)

Fixed In Version: tfm-rubygem-katello-3.9.0-0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1646744 (view as bug list)
Environment:
Last Closed: 2019-05-14 12:37:33 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:1222 None None None 2019-05-14 12:37:41 UTC
Foreman Issue Tracker 24126 None None None 2018-07-02 11:54:02 UTC

Description Corey Welton 2018-06-29 23:05:56 UTC
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:

Comment 2 Corey Welton 2018-07-02 02:49:40 UTC
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).

Comment 3 Tomas Strachota 2018-07-02 11:54:00 UTC
Created redmine issue https://projects.theforeman.org/issues/24126 from this bug

Comment 4 jcallaha 2018-07-02 19:53:43 UTC
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."

Comment 5 pm-sat@redhat.com 2018-07-29 10:27:49 UTC
Upstream bug assigned to afeferku@redhat.com

Comment 6 pm-sat@redhat.com 2018-09-20 22:06:49 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24126 has been resolved.

Comment 7 Patrick Creech 2018-09-21 01:32:04 UTC
Amir,

This failed cherrypick downstream.  Can you take a look?

Comment 8 Kavita 2018-09-25 14:18:30 UTC
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.

Comment 9 Patrick Creech 2018-09-25 15:15:08 UTC
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

Comment 10 Mike McCune 2018-09-25 15:17:58 UTC
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.

Comment 14 Stephen Wadeley 2018-11-14 09:38:12 UTC
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

Comment 17 errata-xmlrpc 2019-05-14 12:37:33 UTC
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


Note You need to log in before you can comment on or make changes to this bug.