diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index e1197ef7..49f3ec42 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -41,147 +41,30 @@ CURRENT ROADMAP - Ability to upload v7 data from DataDump plugin ************************************************************************************************************************************************************************** +COMPLETED: +STAGE 1 CURRENT TODOs =-=-=-=-=-=-= -@@@@@@@@@@@ ROADMAP STAGE 1 and 2: +@@@@@@@@@@@ ROADMAP STAGE 2: - -todo: stuff below go-over and make sure nothing missed - +todo: TEST Picklist on iPad, and shitty lenovo tablet todo: modify Widget form to use picklist to select user, test with huge tracts o'data -todo: server generate data, can I just automate it like with the debug startup code so that I don't have to keep fucking around generating data on every server reboot? -todo: on device testing of picklist (upload to server) -todo: once get here go back to server project todo which is documentation I believe at this point - - probably deserves it's own page as we want each topic small and focused, not a huge page of text in the user docs - - -PICKLISTS: - -AUTOCOMPLETE - TODO FROM PLANS: - CLIENT UI - - WHERE USED - - Only used for *selection* on forms - - Not used in any main grids or in reports (unless people hit the PickList route in code behind the report) - - CONTROL: - - Use tagpicker as basis, already implements most of this - - Uses route at server that is dedicated to all picklists, accepts a type and search phrase returns results - - Must be a custom control even if it's just a wrapper around a regular autocomplete for future proofing - - Accepts a AyaType and handles all the rest automatically by knowing how to query the server? - - TEMPLATE editor, selects and display format for each major object type - - similar to datalistview editor but without filtering ability - - only one template per picklist type with option to default back to default - - Sane default with enough stuff to make it likely they won't bother to change it unless they need to - - SERVER - - SEE SERVER SPEC DOC core-picklist-autocomplete-template-system.txt - - - autocomplete / search involves all displayed template columns (including tags if present in template) - - - - - - - - -currently in v7: - - All picklists in v7 windows are autocomplete based on the START of the phrase typed only - - i.e. if you type in a Project box "pr" you will get "Project A", "Project B" but not a project called "ABC Project" as it doesn't search *in* the values - - This is simple and easy to intuit, maybe we don't need to get too far ahead of ourselves here. - - I do like the option of using tags in search and also a template that can be ordered like part display format for all this - -IDEAS: - - AUTOCOMPLETE / SEARCH - - SEARCH *IN* - - Search in v7 was only start of string so search IN will be very helpful to people and a step up - - For example in v7 if a item was templated like Unit display format with manufacturer first, then search will start with manufacturer - so you couldn't search for the model number first or something, you had to start exactly at the start with the manufacturer - - - DISPLAY TEMPLATE - - COMBINED WITH DATALISTVIEW or it's own thing? - - Potential differences between dlv and PickListView - - Only one default per object type, can't make many, so fixed collection of them - - No filtering combined with it - - Server has code that looks for datalist views generically to display a list of them or fetch them in a factory - - Client sends the template to the server to get the dlv, but a picklist is fixed though customizable for all users so client doesn't need to send it except when editing - - PLV need to be cached at server as they will be hit hard on nearly any form being opened - - Similarities between dlv and PickListView - - consumes a list of available fields pre-defined on a collection - - order and visible are settable by end user - - - NAMING: - - "PickListView" - - In v7 display formats are used for the following: - - All picklists of that type - - In all main grid lists where that type is a JOINED display value not the main one: - - e.g. for UserNameDisplayFormat template: UserList just shows fields like name as they are, but Project list shows the project overseer (User) with the templated setting - - PROBLEM with v7 in filtering that combined column it actually only operated on the primary column name like "name" - - e.g. setting a filter on the workroderitempart list Part column of "eye" would not bring in part named "Thompson eyephones" becuase underlying it was searching only the part number field - - NOT IN GRIDS - - I think I can do away with the v7 feature of using the display format in joined tables of the main grids - - It didn't filter properly - - All JOINED table fields can be provided separately anyway for reporting and viewing and they would actually work with filtering - - NOT IN REPORTS - - Joined tables can be provided and combined in any way user wants on report so not a MUST have as it's fulfilled anyway - - - Fixed, i.e. user can't insert their own characters in the display format but has a fixed method of separating fields - - - Was thinking the DataListview stuff would be enough for picklist templates but actually there is very little real overlap here - - Maybe a kind of similar feature but focused on picklists instead? - - Selection templates for each object by TYPE? - - One central one, not unique to each user because..chaos. - - LINKED OBJECTS / TEMPLATES - - When you think about it there are few things that need to be linked for a template to display/search - - For example in v7 to make any display template for a Unit it needs Vendor name, Model name, Model number, Unit Serial number, Description - -that's 5 items of text info from at most 3 tables, it could just always query those three tables or fixup the query on the fly to minimize table joins - - So you could give the user the options of several text fields pre-defined, they set the order in the template and it searches and displays based on that - - - - - TAGS - - How important are tags for initial release really? - - People want keyboard focused not a lot of clicking, so searching by tags is a bit of an issue: - - Maybe tags can be supported by a special typing sequence like enclose in special characters to search by tag like: - "{orange,red,yellow} Proj" - - OR, MAYBE have parallel selects beside (or above) each other, from left to right, top down or whatever, TAGS is first in row, then actual drop down of names - - if don't select a tag or clear it then only names are taken into account - - Most important first but they go as pairs in the same component - - TAG part displays very minimally at first unless it's been activated or selected (maybe an icon on the outside of the regular select which switches to tag mode?) - - -OLD RESEARCH AND NOTES - - This article is spot on and I need to implement it like this: http://jeremymikkola.com/posts/2019_03_19_rules_for_autocomplete.html - - Check article responses and comments here for tweaks: https://news.ycombinator.com/item?id=19438826 -todo: CLIENT PICKLIST DATALISTVIEW selector form - - Will need under useroptions a central location to choose all datalistview for every type of picklist in AyaNova - - User can leave at default or select a saved DataListView (or make one there) to use - - Client will then pick up that format in any form where it's required - -todo: MAKE PICKLIST COMPONENT Select lists and filtering by tag "select-search-filter-control" - - Implement it as a component with built in searching and tag selection that is sticky by individual form item - - this is an important crucial item and needs to be easy and clean - - I'm thinking it auto searches by entry like RI, but you can open more UI and select tags to filter with it - - Or maybe it's part of datafilter too? - - See add food filter in diary in chronometer app for inspiration (though theirs is a bit dumb, you can only select one tag) - - - - -=-=-=-=-=- AP - After Picklist =-=-=-=-=-=-=- - -todo: TEST on iPad, and shitty lenovo tablet - +todo: check picklist current default templates are adequate for now +todo: picklist template editor UI at client end +todo: document how to use picklist in user docs todo: login form on mobile (and desktop) is scrunched to the top, logo with almost no headroom, would like to see it all centered - todo: now that we have case insensitive should I port that shit over to the datagrid filter as well? - todo: Utilize new picklist in Widget form to select something that exists and can then test out DataListView etc todo: Should all icons be specified from a central location for future proofing and consistency? + - Not sure after initial look at it if this is a good idea or not, think about again + - consider the finished product and how many forms etc + - What *is* a good idea is to remove the code that auto-prepends "fa-" to icons and enforce them as whole strings + - This way can search for icons properly in code even if not centrally situation - right now I just specify they willy nilly and some with fa and some have functions that append fa - if I had a central object with keys that represent the concept of the icon then I can use that everywhere and it's an easy change all at once if something needs changing