This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user