Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CRM-21637 - Search Criteria for Card Type ID and Card Number not resp… #11495

Merged
merged 2 commits into from
Jun 15, 2018

Conversation

yashodha
Copy link
Contributor

@yashodha yashodha commented Jan 9, 2018

…ected in Batch

Overview

Steps to replicate

  1. Create a new accounting batch
  2. Filter on Card Type ID and Card Number, click search
  3. It shows all results irrespective of credit card type and number

Before

criteria

result_before

After

after

@yashodha
Copy link
Contributor Author

yashodha commented Jan 9, 2018

@monishdeb Can you please check this?

@pradpnayak
Copy link
Contributor

pradpnayak commented Jan 9, 2018

@yashodha The SS for after looks wrong.

The changes look good for me. @monishdeb has been working on refactoring the code to search financial transaction list to use api so that the result can be altered using hook.

@yashodha
Copy link
Contributor Author

yashodha commented Jan 9, 2018

@pradpnayak What looks wrong, can you please elaborate?

Also it seems if multiple options are selected for filter criteria it is NOT working
eg, Filter on payment instrument = credit card, debit card fails with DB error while it works for single option

@monishdeb it is because where clause is not built properly

@eileenmcnaughton
Copy link
Contributor

test fail looks related (style issue)

@yashodha
Copy link
Contributor Author

@eileenmcnaughton @monishdeb
all tests pass

@monishdeb
Copy link
Member

monishdeb commented Jan 12, 2018

@yashodha actually like Pradeep said, I am working on an issue about refactoring the code to replace the query with EntityFinancialTrxn api to retrieve batch transactions and here's the PR #10395 which is 70% done and about to complete by this week itself.

Although the current patch fixes the issue as I have tested on my local and ok to merge. But I am afraid the current fix is obsolete as it will be replaced by #10395 .

@pradpnayak
Copy link
Contributor

pradpnayak commented Jan 12, 2018

@yashodha I meant screenshot(SS) you attached initial was of some report. I guess you updated it.

@yashodha I agree some fields on search criteria fields are not respected. I believe @monishdeb will be covering all this in his fix hopefully.

@eileenmcnaughton
Copy link
Contributor

@monishdeb do you want to make a call here - this is pretty trivial so I think it is probably OK to be merged. The lack of tests gives me pause but I think it could squeak through without them & it seems the bigger change got deprioritised / too hard.

@monishdeb
Copy link
Member

monishdeb commented Jun 15, 2018

@eileenmcnaughton I agree, its a trivial but essential fix. Earlier I was hoping to complete the refactoring changes made in #10395 but it will take a long time as I encountered a limitation while changing the search query. I am happy to merge it without UT as it doesn't hit any big change plus the fix is pretty simple and straightforward. Tested again on local and works fine.

@monishdeb monishdeb merged commit 58d4a38 into civicrm:master Jun 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants