Skip to content

Conversation

@AIlkiv
Copy link
Contributor

@AIlkiv AIlkiv commented Aug 20, 2025

These filters are mainly used for View.

image

In this PR, I covered the following column types with tests:

  1. text
  2. number
  3. selection (single, check, multi)

In the future, I will try to add tests for other column types and check AND/OR operators.

@AIlkiv AIlkiv requested review from blizzz and enjeck as code owners August 20, 2025 12:50
@AIlkiv AIlkiv force-pushed the chore/add-unittest-for-view-filters branch 2 times, most recently from 26aec92 to 46d29ed Compare August 20, 2025 13:19
Comment on lines 357 to 369
/* currently not work (frontend filter settings not support multiple values)
'Skills is equal to "Management", "Communication"' => [
[[['columnId' => 'skills', 'operator' => 'is-equal', 'value' => ['@selection-id-9', '@selection-id-10']]],
['Bob'], // Person with skills "Management" (id: 9) and "Communication" (id: 10)
'Filter by skills exactly equal to "Management" and "Communication" - should include 1 rows, exclude 4'
],*/
/* currently work only frontend
'Skills contains "Pyt"' => [
[[['columnId' => 'skills', 'operator' => 'contains', 'value' => 'Pyt']]],
['Alice', 'Charlie'], // People with skills "Python" (id: 3)
'Filter by skills containing "Python" - should include 2 rows, exclude 3'
],*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these don't work, no need keeping them? Might as well remove?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to keep them.
Because we need to synchronize filters with the front end in order to paginate on the server in the future.

#941

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer removing them in the meantime. Who knows when in the future we'll do anything, and it could get messy if we start commenting things like this

/**
* Converts selection values to IDs based on selection_options
*/
protected function convertSelectionValuesToIds(int $columnId, $value) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this still works with #1887. Gonna merge that shortly

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a rebase, it works

],
'Experience years is greater than 5' => [
[[['columnId' => 'experience_years', 'operator' => 'is-greater-than', 'value' => 5]]],
['Eve'], // People with experience 8, 7 years
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be this?

Suggested change
['Eve'], // People with experience 8, 7 years
['Eve'], // Person with experience 7 years

Comment on lines 292 to 293
['Alice', 'Eve'], // People with experience 5, 8, 7 years
'Filter by experience years greater than or equal to 5 - should include 3 rows, exclude 2'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we including 3 or 2? We have just Alice and Eve?

'score' => 92.0,
'status' => 'Inactive',
'skills' => ['Management', 'Communication'],
'is_available' => '"false"',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it intentional not to have experience_years for Bob?

Comment on lines 302 to 303
['Alice', 'Bob', 'Charlie', 'Diana'], // People with experience 2, 3, 5 years
'Filter by experience years lower than or equal to 5 - should include 3 rows, exclude 2'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also confused here

Comment on lines 307 to 309
['Bob'], // No person with empty experience years
'Filter by experience years is empty - should include 1 rows, exclude 4'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, so it's intentional for Bob not to have experience? So the comment saying No person is not correct?

@github-actions
Copy link
Contributor

github-actions bot commented Sep 4, 2025

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

@AIlkiv AIlkiv force-pushed the chore/add-unittest-for-view-filters branch from 46d29ed to 62f2d6d Compare September 4, 2025 06:04
@AIlkiv
Copy link
Contributor Author

AIlkiv commented Sep 4, 2025

@enjeck I did a git rebase and made changes according to the comments.

@AIlkiv AIlkiv requested a review from enjeck September 4, 2025 07:33
@blizzz
Copy link
Member

blizzz commented Sep 26, 2025

Is it possible that DatabaseTestCase.php is not being run? As the phpunit.xml specifies the suffix being Test.php.

@AIlkiv
Copy link
Contributor Author

AIlkiv commented Sep 27, 2025

@enjeck @blizzz I don't understand what to do with this PR. I can see now that another commit ( e4f0753 ) has been made that overlaps this PR by more than 50%. It's not as simple as rebasing these commits, as they are incompatible.

And this PR was only the first part.
I planned to cover all field types, because each field type usually has a separate implementation.
What is your vision? Do you think it is enough to cover key cases, or should everything be covered completely?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants