Fix: issuesList counting #880
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
murilx
force-pushed
the
fix/issue_list_count
branch
3 times, most recently
from
467cf8c to
254d79f
Compare
MarceloRobert
commented
Feb 10, 2025
There was a problem hiding this comment.
It seems that in the example there are some issues with version 0 that are being listed even though only the version 1 is present, the ones starting with "[logspec:generic_linux_boot]". I also noticed this problem in this other example
murilx
force-pushed
the
fix/issue_list_count
branch
2 times, most recently
from
088bb58 to
d6e0f11
Compare
MarceloRobert
commented
Feb 12, 2025
murilx
force-pushed
the
fix/issue_list_count
branch
from
d6e0f11 to
53c00ce
Compare
MarceloRobert
commented
Feb 12, 2025
There was a problem hiding this comment.
LGTM. This PR was started by me but was handed to @murilx, so he can approve it on my behalf
murilx
approved these changes
Feb 12, 2025
- Renames processed_issues to issue_dicts - Separates processed_tests from decide_test_in_filter - Update getIssueFilterLabel to check explicitly for undefined - Update key prop from IssuesList div to include issue version Closes #872
Included issue_version in all issue-related filters that didn't have them yet
When using the Django ORM, that does not support composite primary keys as used by the Issues model, it would produce the incorrect join between Issues and Incidents since it don't consider issue.version when performing the join. To solve this, the django ORM query was replaced by a raw query. That required some of the data to be treated in the pydantic level since it was being fetched as string instead of dict
murilx
force-pushed
the
fix/issue_list_count
branch
from
53c00ce to
612360c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #872
How to test
You can verify that filtering by issues in this localhost page is working properly, while staging page is showing the problems cited in the issue (issues list not showing all issues, filtering by the unlisted issues through the modal causing errors, etc.)
Known issues
While testing this I found out a seemingly unrelated problem with this task, where filtering by an issue will always return the "jobs" (boots/builds/tests) with the latest version instead of the selected version of the issue. This is in more detail in this issue:
UPDATE: It seems that this issue was caused by how the Django ORM was performing the JOIN in the issues table instead of by the filtering system. This was solved in this PR and I'll close this issue as well when this PR is merged
Visual Reference
Before
After
