Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1878879 - [RFE] Maintain/Enable custom reports through Satellite patching/upgrade
Summary: [RFE] Maintain/Enable custom reports through Satellite patching/upgrade
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Reporting
Version: 6.7.0
Hardware: All
OS: All
unspecified
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Lukáš Hellebrandt
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-14 18:25 UTC by patalber
Modified: 2020-10-15 13:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-01 07:09:10 UTC
Target Upstream Version:
patalber: needinfo-


Attachments (Terms of Use)

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.


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