Bug 1321826 - When creating new organization, host selection step won't show, if the user is n context of different organization.
Summary: When creating new organization, host selection step won't show, if the user i...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Content Management
Version: 6.0.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: Unspecified
Assignee: Shimon Shtein
QA Contact: Lukas Pramuk
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-29 08:46 UTC by Shimon Shtein
Modified: 2019-09-26 14:47 UTC (History)
6 users (show)

Fixed In Version: foreman-1.11.0.13-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-27 11:00:46 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 14369 0 None None None 2016-04-22 15:55:39 UTC
Foreman Issue Tracker 14724 0 None None None 2016-05-04 11:29:01 UTC
Red Hat Bugzilla 1338527 0 unspecified CLOSED Assigning hosts on organization creation causes step 3 to be skipped 2021-02-22 00:41:40 UTC

Internal Links: 1338527

Description Shimon Shtein 2016-03-29 08:46:43 UTC
Steps to reproduce:

1. Make sure you have a host without organization.
2. Pick an organization for your context (Make sure you have organization name instead of "Any context")
3. Create a new organization

Expected: Redirection to "Step 2" - hosts selector

Actual: Redirection to Edit organization screen.

The problem is in #count_nil_hosts, it uses Host.where(taxonomy_id => nil).count to check for unassigned hosts.
By default this is scoped:
<pre>
Host.where(taxonomy_id => nil).to_sql
#=> "SELECT \"hosts\".* FROM \"hosts\"  WHERE \"hosts\".\"type\" IN ('Host::Managed') AND \"hosts\".\"location_id\" IN (12) AND \"hosts\".\"location_id\" IS NULL"
</pre>
This query will always return 0.

Comment 1 Shimon Shtein 2016-03-29 08:46:46 UTC
Created from redmine issue http://projects.theforeman.org/issues/14369

Comment 3 Shimon Shtein 2016-03-29 09:00:18 UTC
This is part of https://bugzilla.redhat.com/show_bug.cgi?id=1317846

Comment 4 Bryan Kearney 2016-03-29 10:05:37 UTC
Upstream bug assigned to sshtein@redhat.com

Comment 5 Bryan Kearney 2016-03-29 10:05:39 UTC
Upstream bug component is Organizations and Locations

Comment 6 Bryan Kearney 2016-04-12 12:05:49 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/14369 has been closed
-------------
Shimon Shtein
Applied in changeset commit:b597a8a5fea1e103af2d81b548b319ebdc92aa5c.

Comment 7 Og Maciel 2016-04-14 14:31:19 UTC
To verify this issue, there are 2 scenarios that need to be tested:

1. Creating a new organization when there's a host that is **not** associated to any existing organization

When you have an existing host (perhaps your own Satellite instance) that is not associated to any organizations, then the new Organization process/wizard should take you through all 3 steps: 

  1. Create Organization
  2. Select Hosts
  3. Edit Properties

I was able to verify this scenario using Satellite 6.2.0 SNAP 8.1

2. Creating a new organization when there's a host that **is** associated to one of the existing organization

For this scenario, if there are no existing hosts that are **not** associated to an organization, then the new Organization process/wizard should should skip the second step and the workflow should be:


  1. Create Organization
  2. Edit Properties

I was not able to verify this scenario and steps 2 and 3 were bypassed.

Both of these can be seen in the following video:  https://omaciel.fedorapeople.org/Bug1321826.m4v

Comment 8 Og Maciel 2016-04-14 14:41:18 UTC
Furthermore, for the first scenario described on comment #7, if you choose to Assign all existing un-associated hosts to your new organization, then Step 3 is bypassed as well.

Once you don't have any un-associated hosts available, the new Organization process/wizard will always bypass Steps 2 and 3.

Comment 9 Og Maciel 2016-04-14 14:57:02 UTC
Unfortunately I was not able to test scenario #1 on a Satellite 6.1.8 system but scenario #2 and what I wrote on comment #8 can be easily reproduced on Satellite 6.1.8 system as well.

Failing this issue.

Comment 11 Shimon Shtein 2016-05-04 11:31:06 UTC
Katello overrides foreman's redirection behavior. Should be re-tested after http://projects.theforeman.org/issues/14724 is brought downstream.

Comment 12 Bryan Kearney 2016-05-04 12:14:52 UTC
Upstream bug component is Content Management

Comment 14 Tomer Brisker 2016-05-22 14:10:43 UTC
I verified both scenarios in comment #7 on Snap 12.
The issue in comment #8 remains - selecting "Assign all" or "Manually assign" causes step 3 to be skipped, but it is a separate issue - opened BZ 1338527 for it.
Marking this as verified.

Comment 15 Bryan Kearney 2016-07-27 11:00:46 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/RHBA-2016:1501


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