SR-117877 · Issue 178627
Report on implementation classes corrected for descendant class
Resolved in Pega Version 7.1.8
Report definition was not using implementation class even when 'report on descendant class' was checked. This was caused by an access group changed in RAQ not being reflected into DAQ. When a Data-Admin-Requestor has a Access group which isn't the default, the default authentication doesn't occur and as such the application data page isn't created for the requestor. The lack of an application page causes the code to not determine the associated implementation class for the report definition. This has been changed to use the access group from DAQ only if it is newer than RAQ.
SR-117877 · Issue 175972
Report on implementation classes corrected for descendant class
Resolved in Pega Version 7.1.8
Report definition was not using implementation class even when 'report on descendant class' was checked. This was caused by an access group changed in RAQ not being reflected into DAQ. When a Data-Admin-Requestor has a Access group which isn't the default, the default authentication doesn't occur and as such the application data page isn't created for the requestor. The lack of an application page causes the code to not determine the associated implementation class for the report definition. This has been changed to use the access group from DAQ only if it is newer than RAQ.
SR-118224 · Issue 182305
Report Definition "Pick Value" list resolves to correct layer
Resolved in Pega Version 7.1.8
When a report definition in the framework layer has "Report on descendant class instances" checked, running the report from the implementation layer should retrieve pick list values for "Available Values" on filter popup from the implementation layer. Instead, it was getting the values from the framework layer. This was caused by the code that generates the SQL query to populate the "Pick Value" list resolving to the wrong work class name, using the framework layer work class rather than the implementation layer work class. There was a workaround of performing a 'Save As' of the affected reports to each implementation layer, but this has been fixed.
SR-118224 · Issue 182203
Report Definition "Pick Value" list resolves to correct layer
Resolved in Pega Version 7.1.8
When a report definition in the framework layer has "Report on descendant class instances" checked, running the report from the implementation layer should retrieve pick list values for "Available Values" on filter popup from the implementation layer. Instead, it was getting the values from the framework layer. This was caused by the code that generates the SQL query to populate the "Pick Value" list resolving to the wrong work class name, using the framework layer work class rather than the implementation layer work class. There was a workaround of performing a 'Save As' of the affected reports to each implementation layer, but this has been fixed.
SR-119715 · Issue 178060
Corrected Microsoft Internet Explorer horizontal scroll bar access within large list views
Resolved in Pega Version 7.1.8
If the data present in the list view is huge (2000+ characters), selecting the filter option caused the horizontal scrollbar to not be visible in Internet Explorer. As a result, the apply button was not accessible. This was caused by a lack of overflow settings to handle the excessive width for that browser, and has been fixed.
SR-120324 · Issue 179256
Corrected DateTime controls in GroupBy
Resolved in Pega Version 7.1.8
Specifying any of the DateTime-* controls (e.g., DateTime-Short) in the Format field of the Group By property in a summary view was not working with the out-of-the-box settings; the DateTime property would be displayed in DateTime (GMT) format. This was found to be a field name hard coded to a value with a data type of text, causing the selected control to be ineffective, and has been changed.
SR-120592 · Issue 183002
Corrected circumstanced list views called from within a section
Resolved in Pega Version 7.1.8
A circumstanced List view based on a property was not being properly called from within a section. Instead of passing the primary page which has the circumstance property details for the ruleset work flow, a new page was always created. Since the new page did not have the circumstance property details, the circumstanced list view was skipped. To correct this, the Rule-Obj-ListView.DisplayView rule has been modified to always pass the primary page instead of creating a new one.
SR-120673 · Issue 185098
Refresh behavior updated for sections with list views
Resolved in Pega Version 7.1.8
After configuring a refresh section on a control with a list view in the section, the refresh was happening only on the first iteration. This was an issue with loading "pega_tools_evaldomscripts.js" multiple time and the HTML has been updated to ensure the "ListViewHeader" rule uses the tag instead of tag.
SR-121746 · Issue 182390
Country code TLS (Timor-Leste) added for FieldValue
Resolved in Pega Version 7.1.8
In the ruleset Rule-Obj-FieldValue, the country code TLS (Timor-Leste) was missing for localization. This has been added.
SR-122618 · Issue 185154
SetNewReportColumn now defaults to 20px
Resolved in Pega Version 7.1.8
No nominal column width was assigned to new columns added to a report. If the other columns in the report had an assigned cumulative width that exceeded the width of the browser window, the added column was not visible or selectable either in the Report Editor or in the Report viewer. The added column behaved as if it had zero width. To resolve this, SetNewReportColumn has been modified with a default of FieldWidth as 20 and FieldWidthUnit as px.