INC-175797 · Issue 662048
Date/time filter works in source column
Resolved in Pega Version 8.7
The date/time filter was not working in the Source column for a report definition. This was traced to "pxCreateDateTime" resolving and storing the pyDataType in the report as "DATE TIME". While "DATE TIME" is an acceptable data type it was not supported by pzGridSortPaginate and thus the filter did not work. This was a missed use case, and has been resolved by updating pzGridSortPaginate to check the dataType as both "datetime" and "date time".
SR-B90076 · Issue 341632
Pagination fixed for customized reports
Resolved in Pega Version 8.1
When a report has Header display set to 'Hide column headings' or 'Summary/sort options only', clicking on the navigation page index did not display any further pages. This was caused by malformed HTML that caused the page change to not get picked up, and has been fixed.
INC-178872 · Issue 668306
Added handling for silent save fail with invalid cache
Resolved in Pega Version 8.7
When Commit threw an exception, the Save button from rule form did not catch it and returned no errors even though the save failed. Investigation found this could occur on systems with invalid caches, and a try-catch has been added to handle an exception occurring in a Java step that should not stop future processing.
INC-161463 · Issue 638003
Case Dependency corrected for different access groups
Resolved in Pega Version 8.7
Creating a queue item as part of the case dependency was not working as expected when the access groups of the dependent cases were different. Investigation showed that in this scenario, the logic was looping differently and the DependencyList page in pxCheckFlowDependencies was getting removed. To resolve this, the DependencyList page has been moved so it is processed inside the DependencyList.pxResults loop.
INC-154254 · Issue 674945
Correct Email Bot training text highlighted
Resolved in Pega Version 8.7
When a piece of text was selected and tagged against an entity while training the Email Bot, the entity selection was misplaced and partially covered the actual text selected. The incorrect selection was then carried forward to the training data spreadsheet. To resolve this, rule changes have been made that will update HTML entities to HTML encoded forms.
INC-193727 · Issue 679111
Entity mapping order updated for email bot
Resolved in Pega Version 8.7
Issues were seen with the entity mapping functionality in Email bot, especially when mapping email headers like subject, from (email) etc. to case properties. This was an issue with the order in which the entities were mapped ,and has been resolved with an update that will map entities which are configured in the channel first and then mapping the rest.
INC-178923 · Issue 660885
Resolved startup error related to business calendar object
Resolved in Pega Version 8.7
An error recorded in the log file when the server started was traced to a cache update that removed the old business calendar object and added the new business calendar object to the business cal list. This has been resolved by updating the system to replace the business calendar object instead of removing the old one from the cache first.
SR-C28801 · Issue 374737
Decimal validations fixed for offline mobile case
Resolved in Pega Version 8.1
On a mobile device using offline case it was possible to use multiple entries of grouping_separator without generating an error, but the Presentation configuration of Text Input control did not allow more than one separator in Google Chrome and Microsoft Internet Explorer . Example:"11,22" - worked "11,22.11" - generated error "11.22.22" - generated error "11,22,22" - generated error As a result it was possible to enter values as "12,3,3,3,3,3,3,3." or "12.3.3.3.3.3,4" and submit without any error and the Client Cache would be populated with the expected value "11111.76,null,null,null,null,null,777" , but after sync the clipboard contained "11111.76,null,,null,,null,777" This was due to the present client side validations not supporting validations based on locales, and a new regex expression has been added to pzpega_validators to fix invalid decimal number patterns like 45,,,,5434 , 45....5423 , 43.3,2354 , 54,.42324, etc.
SR-C28801 · Issue 375348
Decimal validations fixed for offline mobile case
Resolved in Pega Version 8.1
On a mobile device using offline case it was possible to use multiple entries of grouping_separator without generating an error, but the Presentation configuration of Text Input control did not allow more than one separator in Google Chrome and Microsoft Internet Explorer . Example:"11,22" - worked "11,22.11" - generated error "11.22.22" - generated error "11,22,22" - generated error As a result it was possible to enter values as "12,3,3,3,3,3,3,3." or "12.3.3.3.3.3,4" and submit without any error and the Client Cache would be populated with the expected value "11111.76,null,null,null,null,null,777" , but after sync the clipboard contained "11111.76,null,,null,,null,777" This was due to the present client side validations not supporting validations based on locales, and a new regex expression has been added to pzpega_validators to fix invalid decimal number patterns like 45,,,,5434 , 45....5423 , 43.3,2354 , 54,.42324, etc.
SR-C38060 · Issue 385590
Timing resolved so pxDateTime control accepts Pega Date Time value on the first input
Resolved in Pega Version 8.1
In Pega Mobile android client, pxDateTime that was displayed within a dateTime field using a calendar selector was throwing an error on the first encounter if the field value was already filled using the Pega DateTime format of "yyyymmddThhmmss.SSS zzz". The console error from the templating engine was: "The specified value "20180605T103556.398 CDT" does not conform to the required format. The format is "yyyy-MM-ddThh:mm" followed by optional ":ss" or ":ss.SSS". " This was traced to the handleNativeDate function in pzpega_control_datePicker.js file executing "pega.u.d.CalendarUtil.fireClientEvents(hiddenInput);" two times. Before firing the first event "onchangehandler" returned null, so the 'if' condition executed to true and fireClientEvents was again getting executed. Because there was no delay in between these executions, the second event was getting executed while the first event was still in progress, causing the DOM value of the property to not be properly set before validation was getting triggered during the second invocation. This has been resolved.