-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[WIP] Save custom reports #1924
Conversation
…into reportsOrganization
This comment was marked as duplicate.
This comment was marked as duplicate.
empty INTEGER DEFAULT 0, | ||
hidden INTEGER DEFAULT 0, | ||
uncat INTEGER DEFAULT 0, | ||
selectedCategories TEXT, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ question: do we even need this? We already have conditions_op
that can be used to filter specific categories. So perhaps we can remove the duplicate DB column?
In the UI we can keep it. But when the user selects to hide a few categories - it just adds a new filter to the view using conditions_op
.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point. Implementing it in my mind seems complex. Maybe there's a better way to do it.
Eg. if you unselect one category you could use "is not" & categoryId. If you unselect all and just choose one you could use "is" & categoryId. When you start adding more and more to either side eventually they meet in the middle.
Or maybe you always use "is any" for field and op. I guess that could work, just thinking out loud. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although it seems like it may be difficult to differentiate actual filters from "selected list". We could always make a new type that combines the two in one array.
viewLegend INTEGER DEFAULT 0, | ||
viewSummary INTEGER DEFAULT 0, | ||
viewLabels INTEGER DEFAULT 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ question: I'm a bit torn about these. From one perspective.. it makes sense to store them in the database. But then the user experience might be a bit jarring.
Let me explain.
Lets say you have 5x widgets with various viewSummary
states. You open up one widget - it opens summary side panel. Then you open a different - it does NOT open summary side panel. Which to me feels a bit annoying. I would expect to have it open everywhere if I had it open before. So to use userPrefs for the global visibility of the summary side panel instead of a per-widget config.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could see an arguement to be made for either side so I guess I'm torn as well. I'd be fine with either implementation. Show/hide of all these elements is pretty quick so I guess I'd lean toward global variables like you suggest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to go with global variables I think.
How would saving reports work with the time options of "year to date" and "last year" would those get saved as raw date ranges and needed re created upon a new year or new month? |
When the report is saved start date is set to currentMonth.firstMonthThisYear and the end dat is set to current month. It's not a dynamicly changing variable that updates with each passing day. I suppose it would be possible to update those dates each time the user opens the report. |
I bet the "last year" option isn't a big deal since that wont change really at all, but the "year to date" one would be nice to have the new months get added. |
If you do setup a way to save a "last year" report it would also be useful to have a this month and last month sliding window. Maybe one option would be to have a few built in ranges that are saved as strings like "last year", "this year", "last month", "last 3 months", "this quarter" and such, then also have the option for a custom window that doesn't change. |
Just linking this for visibility while we're on the topic of sliding windows: #1924 (comment) |
@MatissJanis what are you thoughts on something like this? |
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
I should be able to pick this up again in another week. Just waiting on other PRs to get merged first. |
This PR got too far behind master and became unmanageable to try to fix and bring current. New PR is #2335 |
I have a working prototype for saving custom reports. Rather than working behind closed doors, I wanted to get this out there so people can offer feedback and bug reports. It's working pretty well. I still have some tweaks to make. LMK what you think!