diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 6a7cc1fa..5698b24c 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -6,15 +6,36 @@ ― Marcus Aurelius, Meditations - -todo: NOT import PO's unless they are current, active and unreceived -todo: erase database should reset all id values if they aren't reset already so that future data doesn't result in a new PO starting at 29000 due to huge db trial seed prior +## BIG PICTURE TO RELEASE +March + Contract + Workorder*, quote*, pm* implementations +April + Schedule form + V8Migrate completion + All stock reports (and schedule ones) + 2FA - same as DO authentication code app +May + Manual pages + Extensions to replace current add-on's (accounting etc) + Load testing + Beta testing + Rockfish / Back end infrastructure + Biz decisions about hosting etc +June 1st + Release! MISC ITEMS THAT CAME UP ## CLIENT MISC ITEMS + +todo: NOT import PO's unless they are current, active and unreceived +todo: erase database should reset all id values if they aren't reset already so that future data doesn't result in a new PO starting at 29000 due to huge db trial seed prior + + + todo: bugbug sort a column in data table then remove that column from display will trigger error needs to gracefully handle missing columns @@ -81,38 +102,14 @@ todo: tax codes, taxable objects private Guid mTaxRateSaleID; PurchaseOrder needs to default tax codes when created from global settings -todo: actual Customer report with names populated - - I *was* thinking an alternate data list mode for reporting where there are more defined links in the list to fetch names? - But that doesn't really fit in with the object nature of new reporting as datalist returns will be kind of ugly to work with and also bad for exporting - So I'm back to model populating in biz getreportdata method: - //Note in purchaseorderbiz::getreportdata: - TODO: for reporting this would be more ideal if it populated the displayName fields - //I'm doing that in this object already by fluke, and don't really want to populate them always and in other objects but for reporting maybe - //have a report mode get or I guess just do it all here (but then need for export as well, but then again this is the way it gets for export via getreportdata) - //so perhaps I have a REPORT format of a biz object model and that format has display names mirroring all the fields - //it's fetching it here anyway, might as well do the whole shebang? - So, bottom line might be an alternate ReportModel (e.g. Customer / ReportCustomer) with display fields (not the model sent to the client during normal work as that would eat up bandwidth unnecessarily) - Stop thinking about efficiency too much, this is a time to waste a few cycles but make a much easier to work with data return for reports / export - All display fields are populated as is done with PO similarly and that is done *in* get report data because that's also the export route use too which fits nicely with what I want - Make it work with Customer then backport to all the extant objects and add to item migrate todo list below as a step so it doesn't get missed in future ones - - todo: GetWorkorderSerial/name from leaf nodes traverse up the tree and fetch the serial number once coded fixup in purchaseorderbiz::getasync MIGRATE_OUTSTANDING bit - - - - - todo: v8 migrate additions Erase DB warning must be very distinctive like bright yellow and red with crossbones etc - Report sent *to* the new server upon fail or completion - stored in a location easily found like notes or attach or something on superuser account - (memo to superuser maybe??) + Report sent *to* the new server upon completion (any state) via MEMO to superuser should send the entire contents of the output screen error or not as it will contain useful info like dupes not exported etc Duplicate id not exported found this in the wild with 4a database 4 workorders not exported due to this @@ -123,8 +120,6 @@ todo: v8 migrate additions - - todo: This block isn't necessary anymore as there is a biz rule to catch it: catch (Microsoft.EntityFrameworkCore.DbUpdateException ex) { @@ -137,6 +132,7 @@ catch (Microsoft.EntityFrameworkCore.DbUpdateException ex) throw; } + todo: 2fa is going to be an absolute must have pretty soon, look into what's involved again todo: tag search in picklist, does it support more than one tag? I forget @@ -155,7 +151,6 @@ TODO: //MIGRATE_OUTSTANDING comment tag The tag will contain the description for each - todo: server boot up message should show the port it's listening on if possible or configured to listen on Users may well not know what port they are using and this will ease that greatly @@ -165,7 +160,16 @@ todo: many biz objects are not using new PUT methodology also this includes *all* of the initial workorder object so there's that might be that they don't need it but for consistency should check into it -todo: how to add locale keys in future after release without erasing all data? +todo: Changes to allow in place updates of server: + Needs to be supporting this early as possible so that upon release we can easily make changes without breaking existing setups or forcing complex actions + how to add locale keys in future after release without erasing all data? + Ideally I'd like to continue on to just edit the json translation files and the server looks for missing items and adds them automatically + so that it just works without having to erase the db + maybe a version on translations so it knows which one it's dealing with? + But then again, if it just checks them all it can fix anything missing automatically in case of fuckery and not assume they are ok + Stock locales can just be completely replaced at any time, custom ones need a fixup, + Custom locales should include where they came from (which language) so can more easily add new keys + Schema updates in place not require full delete @@ -632,7 +636,7 @@ todo: workorder UI layout stuff (TTM!! Don't re-invent the wheel!) The whole idea of a completed section of a wo and stuff, is that dropped due to TTM or still viable? maybe can pick out the best new features of that which can be integrated into existing design rather than re-inventing the wheel Here is an overview: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3412 - How best to be able to service LoanUnits on a workorder? + How best to be able to service LoanUnits on a workorder? [UPDATE: added shadow units feature] Just make them Units with extra properties exposed if type of loaner? This seems simplest, but what will it effect? Hard to make them serviceable if they are an alternate table of source for what's being repaired as that breaks a lot of other code or adds exceptions @@ -835,7 +839,7 @@ https://www.youtube.com/watch?v=zZVoo5AbANI @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@ ROADMAP STAGE 11 - RELEASE SELF SERVE / HOSTING @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ - Fall of 2020 hopefully + Fall of 2021 hopefully links on website for sign up marketing can begin in earnest