(refactor) Deprecate automatic equals filters #1454
Labels
Comments
jniles
added a commit
to jniles/bhima
that referenced
this issue
Jun 2, 2017
This commit migrates the server-side code to use FilterParser without autoParseStatements turned on. It removes a test invalidated by this change, as well as cleans up a few whitespace issues in other modules. Partially addresses IMA-WorldHealth#1454.
4 tasks
jniles
added a commit
to jniles/bhima
that referenced
this issue
Jun 5, 2017
This commit migrates the server-side code to use FilterParser without autoParseStatements turned on. It removes a test invalidated by this change, as well as cleans up a few whitespace issues in other modules. Partially addresses IMA-WorldHealth#1454.
jniles
added a commit
to jniles/bhima
that referenced
this issue
Jun 5, 2017
This commit migrates the server-side code to use FilterParser without autoParseStatements turned on. It removes a test invalidated by this change, as well as cleans up a few whitespace issues in other modules. Partially addresses IMA-WorldHealth#1454.
bors bot
added a commit
that referenced
this issue
Jun 5, 2017
1760: refactor: update invoice registry to latest standards r=sfount This PR updates the Invoice Registry to the latest standard. It should help developers of other registries figure out how to update their registries as well. ~~**Note**: The 5K+ line change is because I've committed a package-lock.json file that comes by default with npm v5+. You can find it in the [release notes](https://github.com/npm/npm/releases/tag/v5.0.0). If you would prefer me to remove it and us to ignore it, that's cool.~~ I've removed the `package-lock.json` as it appears to cause issues with previous NPM versions. For reference of what changed, all components of #1749 were tackled here. #### Code Changes 1. I've refined the `FilterParser` implementation on the server by turning off `autoParseStatements` (see #1454). Every filter must be specified. I've also changed cashReference comparison statement to convert the binary uuid in JS, since this is what most other modules do. 2. I've migrated the filters to using the client `FilterService`. 3. I've ensured the filter modal to latest standards. This includes using `bhClear` (see #1702). 4. The end-to-end tests have been updated to reflect these changes. They now use a combined `SearchModal` service, shared with the Cash Payments Registry. It provides simple control of the filters. 5. Two options for downloading have been added: PDF and CSV. For uniformity, they both use the server to serve files to an HTML `<a href download>` tag. If needed, I can try to implement the CSV rendering with the Exporter service ... but I worry about the difference in UX. I'll look to review for guidance. 6. I've implemented the GridState service on this grid. It works as the Journal's works. 7. I've implemented the Grid Column service. It also uses the GridState as described above... however, there is a bug in the Grid Column service reported in #1759. #### A Note on End to End Tests I've combined the Cash Payment Registry's `SearchModal` page object with the Invoice Registry's `SearchModal`. Basically, any search form should be able to leverage this page object without writing their own massive test suite. It prefers convention over configuration though, so you'll have to name your controllers `$ctrl`, your search parameters `searchQueries` (as done in the Journal and Cash Payments registry) and your default search paramters `defaultQueries`. #### Screenshots Pics or it didn't happen, right? **New User Interface**  **New Menu Demo**  **Download as CSV Option**  **Column Configuration Modal**  **Column Changes Saved in Save State**  Closes #1749. ---- Thank you for contributing! Before submitting this pull request, please verify that you have: - [x] Run your code through ESLint. [Check out our styleguide](https://github.com/IMA-WorldHealth/bhima-2.X/blob/master/docs/STYLEGUIDE.md). - [x] Run integration tests. - [x] Run end-to-end tests. - [x] Accurately described the changes your are making in this pull request. For a more detailed checklist, [see the official review checklist](https://docs.google.com/document/d/1nupLVLRXgSZJQo_acLgrwvPnN8RukfSiwRhSToj81uU/pub) that this PR will be evaluated against. Ensuring that the above checkboxes are completed will help speed the review process and help build a stronger application. Thanks!
|
Closing this since it has been in master for over a month at this point. We can always reference this later. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
FilterParserservice on the server currently will use ALL options that are passed from the client, if no rule or exception is provided it will try to run theequalsmethod on the key and the value (table.[options.key] = options.value).This behaviour was convenient when we had a small number of filters and it was easy to see that this was happening. Now that we have many different modules performing complex filters I propose that we remove this default functionality and require the programmer to specify each
equals.Benefits:
APIs that have to be updated:
The text was updated successfully, but these errors were encountered: