Bug 1878879

Summary: [RFE] Maintain/Enable custom reports through Satellite patching/upgrade
Product: Red Hat Satellite Reporter: patalber
Component: ReportingAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED NOTABUG QA Contact: Lukáš Hellebrandt <lhellebr>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.7.0CC: daniel.shaver, dmatoule, mhulan, oprazak
Target Milestone: UnspecifiedKeywords: FutureFeature
Target Release: UnusedFlags: patalber: needinfo-
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-01 07:09:10 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:

Description patalber 2020-09-14 18:25:58 UTC
1. Proposed title of this feature request  
Maintain/Enable custom reports through Satellite patching/upgrade
     
2. What are the nature and description of the request?  
Reports that require custom fields need to be maintained through upgrades w/o having to re-work satellite configuration
  
3. Why do you need this? (List the business requirements here)  
Compliance reporting mandated by management and global security
  
4. How would you like to achieve this? (List the functional requirements here)  
For me?  To not have to customize files or change modes in satellite post upgrade.
  
5. For each functional requirement listed, specify how Red Hat and your organization can test to confirm the requirement is successfully implemented.  
We would generate a new copy of the report.
  
6. Is there already an existing RFE upstream or in Red Hat Bugzilla?  
No
  
7. Do you have any specific timeline dependencies and which release would they like to target (i.e. RHEL8.3, Sat7)?  
Probably too late to get this into 6.8 as GA is only weeks away, but sooner than later?
  
8. List any affected packages or components.  
Satellite 6.7 Report Templates
  
9. Would you be able to assist in testing this functionality if implemented?
Yes, but not having a "non-prod" satellite instance would make it a bit difficult to test.

Comment 1 Marek Hulan 2020-09-15 11:51:50 UTC
I am sorry, after reading the request for several times, I still don't understand, what is the expected outcome. If I understand correctly, customer cloned and modified the default template and after update would like to apply same changes we apply to the default template to their clone? I'm not sure how we could achieve that. Some customers may not want their clones to be touched at all. Also some changes may cause conflicts with custom changes.

So I'd like to better understand the expectation here.

Comment 2 patalber 2020-09-23 13:35:10 UTC
Marek,

I have passed along the request to the customer and am awaiting their response.

Thank you.

--Patrick

Comment 3 Dan shaver 2020-09-23 15:32:51 UTC
The intent of the request is not to modify canned reports, but to have upgrades to Satellite not break custom reports.  
This is in reference to RH Case 02740721, where in order to get "custom" fields available within a report, /usr/share/foreman/lib/foreman/renderer/scope/macros/base.rb needed to be edited and safe mode for template rendering needed to be disabled.

The request is that these changes be preserved or at least a warning/notification when the application is upgraded.

Comment 4 Marek Hulan 2020-09-24 10:11:15 UTC
There's no way to avoid this. If customer modifies the source code, customer changes are overriden on ugprade. Modifying a source code is not supported, the correct flow is to raise RFE to add new macros and we ship them in next Satellite version or in urgent cases, we can build a hotfix. When support suggests to modify the source code, the new version of Satellite will override any customization.

If I understand the case correctly, I'd suggest closing this as not a bug.

Comment 5 Marek Hulan 2020-10-01 07:09:10 UTC
A week without reply from the reporter has passed, closing as suggested in previous comment. Please reopen if I missed something, but as stated above, changing the source code to add new macros can't be really supported on upgrades, we need to upgrade the source code during upgrade process.

Comment 6 Dan shaver 2020-10-15 13:48:01 UTC
A separate RFE was opened to add the module to base.  Apologies for not updating.