Bug 1300812 - Subscription math is wrong on Review Subscriptions, when showing existing subs + selected subs
Subscription math is wrong on Review Subscriptions, when showing existing sub...
Status: VERIFIED
Product: Red Hat Quickstart Cloud Installer
Classification: Red Hat
Component: WebUI (Show other bugs)
1.0
Unspecified Unspecified
unspecified Severity medium
: TP2
: 1.0
Assigned To: Erik Nelson
Dave Johnson
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-21 14:19 EST by Matt Reid
Modified: 2016-04-29 12:19 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Reid 2016-01-21 14:19:47 EST
Description of problem:
4D Review Subscriptions looks to have broken logic on calculating how many subscriptions are going to be in the manifest. I selected 3 and then 1 subscription from 2 different pools, and on the review step, it shows that I will have 0 + 3 = 30 and 1 + 1 = 11 Quantity Attached (there was already 1 of the second subscription in the manifest).

If I select 1 of the first and 0 of the second, it shows as 0 + 1 = 10 Quantity Attached and 1 Quantity Attached for the second.

Seems like we're appending/concatenating them (in reverse order), rather than adding the two numbers?

Version-Release number of selected component (if applicable):
current test environment

How reproducible:
100%

Steps to Reproduce:
1. Go through a deployment
2. Select 2 subscriptions to add to a manifest/SMA
3. On review, the UI will tell you that there are 20 attached, with the math 0 + 2 = 20

Actual results:
There are only 2 that will be attached upon deployment, but we say 20 instead

Expected results:
For that example, I would expect 0 + 2 = 2, but in general, for the math of currently attached + will be attached to be correct

Additional info:
Comment 5 Erik Nelson 2016-01-22 08:52:44 EST
PR merged:  https://github.com/fusor/fusor/pull/650

Note: This is unique to the mocked environment, a real server sends correctly typed data. Guards are still good to have.
Comment 6 Antonin Pagac 2016-01-26 06:46:20 EST
Works for me, testing with baremetal machines and CDN. Marking as verified.

RHCI-6.0-RHEL-7-20160122.t.1-RHCI-x86_64-dvd1.iso

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