Filtering feature for logs
:mag: Overview
This initial PR for the issue #129 has the UI update for the filtering feature of logs
:bulb: Proposed Changes
Detail the proposed changes, including new features, bug fixes, or improvements. Explain how these changes impact the project, including any internal structure alterations or refactorings.
:framed_picture: Screenshots or Demo
https://github.com/user-attachments/assets/37e24caf-4e9c-4002-8627-066e2d1d41a2
:memo: Release Notes
Summarize the changes in a user-friendly manner. Highlight new features, bug fixes, and any breaking changes, including migration steps or deprecated functionalities.
:question: Open Questions
If there are aspects of the changes that you're unsure about or would like feedback on, list them here.
:test_tube: Testing
Describe the testing strategy. List new tests added, existing tests modified, and any testing gaps.
:dart: Reviewer Focus
This PR only contains the UI part of the filter for logs. Please verify the UI.
Things left in this
-
A Dropdown view for the user selection similar to this
-
To add Datepicker
:heavy_plus_sign: Additional Context
Provide any additional information that might be helpful for reviewers and future contributors, such as links to related issues, discussions, or resources.
:sparkles: How to Test the Changes Locally
Give clear instructions on how to test the changes locally, including setting up the environment, any necessary commands, or external dependencies.
:green_heart: Did You...
- [ ] Ensure linting passes (code style checks)?
- [ ] Update dependencies and lockfiles (if required)
- [ ] Regenerate graphql schema and types (if required)
- [ ] Verify the app builds locally?
- [ ] Manually test the changes on different browsers/devices?
This looks awesome! Only thing missing in the date picker. You can use a standard html calendar input for now, no need for anything fancy. Also we might need to allow filtering by a specific time range too. There could be a large number of logs generated in a 24hr period, and it would be useful to be able to narrow it down.
Added the fields for selecting time intervels
Should I do filtering action on the data from the front end itself or does it need to write new APIs for the filtering?
Should I do filtering action on the data from the front end itself or does it need to write new APIs for the filtering?
We definitely need to apply filtering logic on the backend, since log data is likely to be very large. Let's extend the existing query resolver for logs with arguments required for these filters. Lmk if you want some help deciding on the spec for these arguments. Remember to keep things modular and allow the frontend to query things in a flexible way.
All the APIs are defined in schema.py right?
All the APIs are defined in
schema.pyright?
Yep, the logs resolver is here: https://github.com/phasehq/console/blob/cb7d3815cbd99e6cab5ee405a69145f8aa9f5639/backend/backend/schema.py#L509