SR-122264 · Issue 182315
Preview Included Section corrected for Case Manager portal
Resolved in Pega Version 7.1.8
The Section Include preview feature was implemented with support in the Developer Studio, but was found to not be working as expected in the Case Manager Portal. This was due to a wrong 'if' condition for span identification, and the system has been updated.
SR-122268 · Issue 184969
Tuned handling for child requestors in unauthenticated listener services
Resolved in Pega Version 7.1.8
While executing Queue instruction through JMS listener service, the error "Rule Not Found" was logged. This exception was due to a child requestor invoking the queue activity using the PegaRULES application instead of the current application. This was a side effect of changes made to the Service API which set the requestor authentication to true when the service package is unauthenticated, a change made to run activities that have enabled 'require authentication'. However, the credentials were not passed; the requestor was authenticated and the child requestor created was still unauthenticated, causing this issue. To resolve this, the system will set the access group from Service layer.
SR-122292 · Issue 182878
Operators and Access Groups are now automatically force re-indexed during import
Resolved in Pega Version 7.1.8
If a number of new OperatorIDs were created and added to two workgroups and then the changes were exported, the new OperatorIDs were present when the file was imported to other environments but a query run against the table PR_INDEX_OPERATOR_WORKGROUP did not incorporate the new IDs. While there was a workaround of manually forcing a re-index during import to fully incorporate the new IDs, the Operators and Access Groups are now automatically force re-indexed during import to ensure data is up to date.
SR-122301 · Issue 182078
Revised max datetime value for validation
Resolved in Pega Version 7.1.8
Previously, a date property could have a max set value of 31-Dec-9999. This max date was not working in some time zones due to the input date being converted to GMT for internal operations. This meant that 31-Dec-9999 in some locales was getting converted to 1-Jan-10000GMT, which then failed validation. To correct this, the datetime validity logic has been changed to use "1st Jan 00:00:00.000 10000 GMT" for validation.
SR-122305 · Issue 181630
Resolved addition of extra lines added upon RTE save
Resolved in Pega Version 7.1.8
After pasting some text (paragraph) content into the out-of-the-box RTE control and saving, new lines were inserted between paragraphs and again every time the save button was clicked, adding more lines. This was caused by a missing redundancy check within the RTE control code that is used to replace '/n' (new lines) with
in order to incorporate proper indentation when the text area is upgraded to RTE. Changes have been made to handle the carriage return case properly.
SR-122305 · Issue 183086
Resolved addition of extra lines added upon RTE save
Resolved in Pega Version 7.1.8
After pasting some text (paragraph) content into the out-of-the-box RTE control and saving, new lines were inserted between paragraphs and again every time the save button was clicked, adding more lines. This was caused by a missing redundancy check within the RTE control code that is used to replace '/n' (new lines) with
in order to incorporate proper indentation when the text area is upgraded to RTE. Changes have been made to handle the carriage return case properly.
SR-122313 · Issue 183428
Database Class Report properly populating Ancestors column
Resolved in Pega Version 7.1.8
When running the Advanced->Reports->Database Class Report, the "Ancestors" column was not populated for tenant level classes. The problem was with the method used to create the report querying the ClassMap using normal, tenantized APIs instead of Shared, so no data was returned. This has been corrected and the class ancestor values are now properly populated in the generated csv file.
SR-122313 · Issue 181185
Database Class Report properly populating Ancestors column
Resolved in Pega Version 7.1.8
When running the Advanced->Reports->Database Class Report, the "Ancestors" column was not populated for tenant level classes. The problem was with the method used to create the report querying the ClassMap using normal, tenantized APIs instead of Shared, so no data was returned. This has been corrected and the class ancestor values are now properly populated in the generated csv file.
SR-122314 · Issue 178491
Resolved installation errors for DB2 Z/OS with WebSphere
Resolved in Pega Version 7.1.8
A problem was encountered while installing split schema on a DB2 z/OS system with WebSphere. This was caused by an erroneous system setting where the ports to the DB2 database were not open in this environment. While the Admin could correct the environment to open the ports and allow the application server node to connect to the DB2 database, this has been changed in the software to default to the correct settings.
SR-122387 · Issue 183319
Expanded BIX error codes
Resolved in Pega Version 7.1.8
When BIX is executed through the command line, it may not return an error code even if BIX has stopped processing because of a failure (for instance when the -f flag has been used). That is, the $? system call may return 0 when an extract has failed. The system has been updated to offer more information thorough error code returns, but when trying to programmatically capture whether a particular run of BIX was successful or not, it would still be advisable to check $? in the script, as this may be returned due to other reasons (such as a java/network/database related problem). This may be augmented by performing a parse on the PEGABIX log file and specifically checking for the text: 'Instances not extracted due to errors: 0'. At the end of each BIX this line will appear with a summary of how many extracts failed. After the BIX portion of the script has completed, it's possible to check how many occurrences of this error appear in the file. If it is one, then this meant none of the extracts produced errors. And if there are none, then either some exports did contain errors, or it didn't reach the part of the code that produces this line (hence an earlier error). This can be incorporated into a script using something like: errorfree='grep "Instances not extracted due to errors: 0" PEGABIX.log | wc -l'