Bug 1785547
Summary: | [UI] Importing Templates - Associate "new" is working as "always" | ||
---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Jitendra Yejare <jyejare> |
Component: | Templates Plugin | Assignee: | Ondřej Pražák <oprazak> |
Status: | CLOSED ERRATA | QA Contact: | Jitendra Yejare <jyejare> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.7.0 | CC: | asharvit, egolov, mhulan, oprazak |
Target Milestone: | 6.7.0 | Keywords: | Triaged |
Target Release: | Unused | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | tfm-rubygem-foreman_templates-7.0.7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-04-14 13:38:52 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1778146 |
Description
Jitendra Yejare
2019-12-20 08:08:31 UTC
Created redmine issue https://projects.theforeman.org/issues/28626 from this bug There is a problem that form ignores current context and does not send the current location/organization on form submit, cloning upstream. Upstream bug assigned to oprazak Upstream bug assigned to oprazak Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/28626 has been resolved. FailedQA ! @Satellite 6.7 snap 15 @tfm-rubygem-foreman_templates-7.0.7-1.el7sat.noarch Steps: --------- As per Description of this bug Observation: -------------- 1. The taxonomies are not being updated in Template from where the templates are being imported. {FAIL} 2. The template is being imported in taxonomies mentioned in template.erb {FAIL} Comment 9 makes me think I misunderstood the reported issue. 1. The taxonomies are not being updated in Template from where the templates are being imported. {FAIL} - Assuming 'taxonomies from where the templates are imported' refers to current organization/location, does this mean import is expected to modify metadata in template? If so, it should be a new RFE as we currently do not modify the content of templates on import. 2. The template is being imported in taxonomies mentioned in template.erb {FAIL} - True if 'associate' setting is set to 'never'. The current behaviour is as follows: A. importing new templates with 'associate: never' imports the templates into current organization/location regardless of taxonomies in template metadata B. importing new templates with 'associate: new' or 'associate: always' and taxonomies in template metadata imports the templates only into organizations/locations specified in metadata. Templates are imported into current organization/location only if their names are specified in metadata. This seems to be the originally expected behaviour as the issue reported templates being always imported into the taxonomies from metadata. Is this acceptable? If not, could you specify the expected behaviour that would resolve this issue? Based on the last comment, can we move it to 6.8 as more information and development is needed? (In reply to Ondřej Pražák from comment #10) > Comment 9 makes me think I misunderstood the reported issue. > > 1. The taxonomies are not being updated in Template from where the templates > are being imported. {FAIL} - Assuming 'taxonomies from where the templates > are imported' refers to current organization/location, does this mean import > is expected to modify metadata in template? If so, it should be a new RFE as > we currently do not modify the content of templates on import. No, it's not about updating the template metadata. But I mean the taxonomies assigned to the template after importing doesnt have current taxonomies. Lets say I import x template from org1 and loc2 then, the imported template is not imported in org1 and loc2. Its associated with the taxonomies which are only mentioned in the template(local_path/x.erb) metadata. Is this expected behavior? For me the expected behavior is, only associating the current taxonomies to imported template and disassociate the taxonomies mentioned in template metadata. > > 2. The template is being imported in taxonomies mentioned in template.erb > {FAIL} - True if 'associate' setting is set to 'never'. The current > behaviour is as follows: Here in my case and in this bug, the associate is set to 'new' and this bug is all about new. > > A. importing new templates with 'associate: never' imports the templates > into current organization/location regardless of taxonomies in template > metadata But does imported template should be imported in taxonomies mentioned in template metadata in this case of 'associate : never'. ? > B. importing new templates with 'associate: new' or 'associate: always' and > taxonomies in template metadata imports the templates only into > organizations/locations specified in metadata. Templates are imported into > current organization/location only if their names are specified in metadata. So here in this bug, the 'new' template with associate 'new', is not being assigned to the current location. It is only being assigned to taxonomies mentioned in template metadata. And thats what this bug is all about :) > > This seems to be the originally expected behaviour as the issue reported > templates being always imported into the taxonomies from metadata. Is this > acceptable? If not, could you specify the expected behavior that would > resolve this issue? See my comments above, Let's have a meeting if this does not answer your questions. After meeting with Oprazak, I have concluded that now 'associate: new' is working as expected: By only importing the templates into the new taxonomies(which are not associated earlier) mentioned in template metadata(metadata can be changed to include the new taxonomies) regardless of current taxonomies. So the observations I made in Comment 9 and 10 are the actual behavior. Hence changing the bug state to Verified! 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-2020:1454 |