Change Details

As part of the daily review of the stopped fraud que, I am pulling all transactions (merchant Reference #'s) stopped at 600 out of Ingenico, sorting Merchant reference #'s, by date, from newest to oldest and submitting them via Civi Fredge to obtain a list of fraud parameters associated with the list I submit. The results I am getting are oddly starting to be randomly scrambled as of 12.2....Coincident to the issue I raised in Phab task https://phabricator.wikimedia.org/T239769 (not sure if it is related at all) which sees erroneous transactions stopped at 600. Please refer to the 600 trx stopped in this spreadsheet : https://docs.google.com/spreadsheets/d/1z8sOMtfgrlb5P0JNKTj_Fq6ba4UCgBo-9EqsLU9yFls/edit#gid=503946220. I've tried to highlight the MR #'s in red that are randomly scrambled. This has not been the case for the last 4 months since I've been driving this process. Is there some reason the Civi query is scrambling the result? The Fredge results are key to decisioning on manually settling transactions or not and the search results appearing out of order protract the time it takes to conduct the review, which is already a high overhead process. Thanks!

DoD * Add these fields to the fredge report Evelyn is using in civi: ** Country ** Currency code ** Order amount ** “TS” the timestamp I which they first hit payments wiki (contribution tracking ) * also the scrambling of results earlier might be an indication that the report might break at high amounts of donations submitted. If anyone can spend time looking at this, that would be great but we don't have large lists to work with at the moment. Original bug report As part of the daily review of the stopped fraud que, I am pulling all transactions (merchant Reference #'s) stopped at 600 out of Ingenico, sorting Merchant reference #'s, by date, from newest to oldest and submitting them via Civi Fredge to obtain a list of fraud parameters associated with the list I submit. The results I am getting are oddly starting to be randomly scrambled as of 12.2....Coincident to the issue I raised in Phab task https://phabricator.wikimedia.org/T239769 (not sure if it is related at all) which sees erroneous transactions stopped at 600. Please refer to the 600 trx stopped in this spreadsheet : https://docs.google.com/spreadsheets/d/1z8sOMtfgrlb5P0JNKTj_Fq6ba4UCgBo-9EqsLU9yFls/edit#gid=503946220. I've tried to highlight the MR #'s in red that are randomly scrambled. This has not been the case for the last 4 months since I've been driving this process. Is there some reason the Civi query is scrambling the result? The Fredge results are key to decisioning on manually settling transactions or not and the search results appearing out of order protract the time it takes to conduct the review, which is already a high overhead process. Thanks!

DoD * Add these fields to the fredge report Evelyn is using in civi: ** Country ** Currency code ** Order amount ** “TS” the timestamp I which they first hit payments wiki (contribution tracking ) * also the scrambling of results earlier might be an indication that the report might break at high amounts of donations submitted. If anyone can spend time looking at this, that would be great but we don't have large lists to work with at the moment. Original bug report As part of the daily review of the stopped fraud que, I am pulling all transactions (merchant Reference #'s) stopped at 600 out of Ingenico, sorting Merchant reference #'s, by date, from newest to oldest and submitting them via Civi Fredge to obtain a list of fraud parameters associated with the list I submit. The results I am getting are oddly starting to be randomly scrambled as of 12.2....Coincident to the issue I raised in Phab task https://phabricator.wikimedia.org/T239769 (not sure if it is related at all) which sees erroneous transactions stopped at 600. Please refer to the 600 trx stopped in this spreadsheet : https://docs.google.com/spreadsheets/d/1z8sOMtfgrlb5P0JNKTj_Fq6ba4UCgBo-9EqsLU9yFls/edit#gid=503946220. I've tried to highlight the MR #'s in red that are randomly scrambled. This has not been the case for the last 4 months since I've been driving this process. Is there some reason the Civi query is scrambling the result? The Fredge results are key to decisioning on manually settling transactions or not and the search results appearing out of order protract the time it takes to conduct the review, which is already a high overhead process. Thanks!