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:
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.
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