admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2020-02-25 19:08:15 +00:00
parent a760f9dea9
commit 5c875c6782
1 changed files with 14 additions and 151 deletions
Download Patch File Download Diff File Expand all files Collapse all files

165
ayanova/devdocs/todo.txt
View File

@@ -42,6 +42,15 @@ CURRENT ROADMAP
CURRENT TODOs
=-=-=-=-=-=-=
TODO: Unsaved filter?
- it triggers some issues making it the odd way out of doing things.
- No way to edit existing filter
- much fuckery in UI dealing with unsaved mode
- takes up space saving it and could be the same all over the UI for all the other stuff ballooning the persisted data in localstorage
- original purpose was to save users live edits to filter when looking at grid
- However, with raven it's a bit weird becuase there is no live edit really, you go into and out of anyway so should it force a save or not
todo: datalistview editor
- showing options for wiki and attach etc, not required need to add override in gzmenu
@@ -52,109 +61,12 @@ TODO: duplicate code unique name at server shows datetime as UTC, find alternati
TODO: have a think about fouralarmfire's situation with crazy high id numbers, do we want to import them as that or...?
- thought of adding a single letter scheme to them to reset or something
TODO: show current filter as text fragment in grid at bottom? (what does this bring?)
todo: tags in ui shows equals seems to imply that all tags must equal selected value, sb contains instead I think becuase that's how it seems to act from user perspective
DataTAble form inits listview as follows:
- Checks if there is a current active unsaved listview in the formsettings for that form and uses it if found
- If no active unsaved listview it then checks for an ID of a listview in formsettings last used and fetches and uses that if found
- If no current unsaved listview nor an ID then it just leaves that blank and let's server use default listview
If user selects to edit listview then ListViewEditor inits as follows:
- Checks if there is a current active unsaved listview in the formsettings for that form and uses it if found
- If no active unsaved listview it then checks for an ID of a listview in formsettings last used and fetches and uses that if found
- Also sets in selection list of listviews (or is that in thsi form)
- If no current unsaved listview nor an ID then it fetchs from the server the default listview and uses that in the form
If user leaves listview form without saving:
- If any changes were made then ListViewEditor persists that listview to the store under the formsettings specified so that form can pick it up
- If no changes were made then nothing is persisted
If user saves view from ListViewEditor
- Overwrites with prompt if they save to same view
User opens datatable is presented with default listview arrangement
Until user opens listview editor the datatable uses the default and doesn't persist a listview
If user opens a ListView editor without any local customizations then it fetches off the server and presents as the default for that DataListKey
If Client makes any changes to a listview they are persisted as a formsetting for that datatable that survive a restart
When datatable form is opened it checks if a persisted formsetting of listview, if found sends that with the request for the list, otherwise listview property is empty
If user selects a listview from the server for the datatable as long as they don't edit it that listview's ID is stored instead in the formsetting.
The moment they edit a listview it's stored in full in local formsetting as the current active.
Client stores the active listview into the persisted formsettings if there are *any* customizations done
Filter UI
- Works with a passed in listview array somehow (from STORE I guess, current list view kind of thing?)
JSON DataListView format:
ONE string of json, not separate
Contains all columns that are relevant each as an object with various props desired to be returned in order
If a column isn't filtered or sorted or included then it isn't in the collection
Order and presence determines sort, filter, return and display order
Each column object contains it's sorted, sort order and filters collection which can be empty
Sort and filter properties are optional and can be omitted
"any" property is optional in a filter and can be omitted
UI: shows all available columns, user sets order by re-arranging and whether to include or not with a checkbox Include which defaults to true if there is any conditions on that column
ID COLUMN FILTER:
These columns could filter by text or by "SPECIFIC" ID so support that:
TODO: DataFilter how to distinguish between filtering on specific ID value or on value column
- Might need to add a filter on ID type of thing maybe?
- This works in v7 by providing a list of items that were displayed for that object in the list so that they can select the particular one and that item's ID is then saved for that column
- For v8 since we know the type of the column we could in theory fetch a list of all items of that type on demand for user to select from if they choose to go that way.
- This way the item doesn't need to be in the source grid like in v7 so it's actually better!!!
Example:
DataListView JSON:
[{key:"COLUMN UNIQUE KEY ID",sort:"-" or "+",filter:{any:true/false,items:[{FILTER OBJECT SEE BELOW}]} }, {key:"second column unique key"},{...etc...}]
Filter object definition:
Has an "any" boolean property which if true means make an OR query of the conditions if more than one, if nore present or false it means AND each condition (if more than one)
filter:{any:true/false,items:[
{op:"OPERATOR",value:One of an array of strings, single string or single value of any supported type, i.e. int, decimal, bool iso8601 date etc }
]}
Filter operators:
public const string OpEquality = "=";
public const string OpGreaterThan = ">";
public const string OpGreaterThanOrEqualTo = ">=";
public const string OpLessThan = "<";
public const string OpLessThanOrEqualTo = "<=";
public const string OpNotEqual = "!=";
public const string OpNotLike = "!%";
public const string OpStartsWith = "%-";
public const string OpEndsWith = "-%";
public const string OpContains = "-%-";
public const string OpNotContains = "!-%-";
TAGS - At server if equality compare value is an array of strings then it's assumed to be tags, if it's a single value then it's regular
Sort / filter / select return columns all in one!
- This combined is a "view" or DataListView (fucking renaming again here we come! :)
- When user opens a data table they see for the first time the default table view and sort order and filter (no filter, sort by id, a few key fields)
- they can make a new view which shows all the fields and they can set props on each one:
- Filter (with filter code)
- in v7 users can set more than one condition per column by selecting "custom" so we need to support that
- Maybe a row of all columns then each one has a expandable list of conditions under it for setting multi filters?
- Like a card with top part all static info, then filters below as a collection that can expand the card vertically with ADD and REMOVE buttons for each one
- In v7 user can set AND or OR query for custom more than one condition (but it applies to the whole group, not both and and or individually)
- Sort
- View order is sort and filter order
- Visible
- Checkbox if visible which means the server returns it or not, visible maybe not correct word here
- This way the user can customize the grid all in one savable setting
- Grid defaults to last "View" that was in use
todo: check if this block about reports and listview is in the spec doc for the listview or reports (maybe in reports better)
- REPORTS
- Report object has following properties:
- DataList name it's based off of
@@ -170,58 +82,9 @@ TAGS - At server if equality compare value is an array of strings then it's assu
- As part of editing process user can select an existing datalistview to prime their report editing view
- A report can be selected from any client table that is based on the same view
- MINI code is not right:
- right now it produces a single column header but can contain multiple columns of data
- this is bad because the client doesn't know the underlying type so can't co-erce each column into locale format
- I'm thinking ditch mini at server and make it a client display issue instead
- There does still need to be a MINI default format though for all lists, hard coded so user can revert or start with a solid PickList
- MINI just same as regular DataListView however Client would display differently munged into one column so up to user what columns in what order!!
- So we need two default views for each datalist, one for grid display and one for picklist display that can be reverted to and are permanent
- User can at any time use the default view or pick a custom DataListView
- All users start with default view and can modify as they see fit
- each form with each picklist would have it's own view possibly?
- IS MINI options a different UI?
- Maybe it *is* different because selects are a kind of unique situation with thier own requirements.
- Can default but also would be hellish if it's customizable user by user since there is probably a company standard for selecting parts for example
- Maybe the "Default" can be set by an admin and users can either select default or go off the books to their own custom
- Reports are a special circumstance, a report really would go with a specfic filter wouldn't it? INVESTIGATE THAT
- View filter set with report? Report needs all fields sometimes but view may not have so what happens then?"
- Show text filter sort fragment at bottom of grid in footer
- PickList of filters for dataListKey (DO I have a server route for that?)
- ListOptions editor
- OWN PAGE NOT combined with data table
- Data Table just has the selection for presaved filters
- UI allows to edit both filters and sort order
- FILTERS: needs to take a list of available fields to select from, pick on adds to collection then can set actual OP and VALUE etc stuff on it based on type
- Build from new, rehydrate view from existing, handle bad column names no longer valid
- uses standard filter column definition to feed UI elements, ideally not a composite array that needs transformation
- See custom fields builder as that is similar
- Code as an component element, perhaps made of other components?
- SORT
- In same UI as the filter builder, probably the most commonly accessed of the two so maybe sort order on top and filter below?
- ListOptions builder
- Need method that builds the list options into json fragments to send to server with datalist request
- ListOptions descriptive text builder
- A Way to show a string of text showing what filter options and sort options were chosen so can be output to reports etc
- DataTAble UI
- Pick list of ListOptions for that list type at top also (no options) empty default choice
---------------------- NON DATALISTVIEW STUFF ----------------------------
TODO: "Unsaved filter" being displayed, sb "Unsaved listview"
TODO: No way to make a new widget now!!!
TODO: save (post) of new record at client triggers renavigation to that page again which also triggers fetch