1127 lines
44 KiB
Plaintext
1127 lines
44 KiB
Plaintext
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
@@@@@@@@@@@@@@@ ROADMAP STAGE 6 - "REALITY" All in on porting over all the real objects from v7
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
|
||
|
||
MISC ITEMS THAT CAME UP
|
||
|
||
todo: standardize routes and route names and form names
|
||
Use plural and singular names throughout for consistency
|
||
i.e. "-edit" forms shoudl be standardized to just th singular name so "part-assembly-edit" sb "part-assembly"
|
||
|
||
todo: help docs and urls sb standardized and shortened / simplified
|
||
for example remove "form-" from names of help files so "form-inv-part-assemblies" becomes "inv-part-assemblies"
|
||
make sure all forms have corresponding help doc by searching for "helpUrl:" and then comparing list
|
||
|
||
todo: select list templates in admin global settings doesn't show the list of objects in alpha order (look at notification maybe there or maybe needs it too)
|
||
also, needs a way to reset to default with one click, maybe a menu option?
|
||
|
||
todo: foreign keys are not indexed by default in the referencing table (the one who references)
|
||
take a look and see if any should be indexed when doing above
|
||
|
||
|
||
todo: PickList controller route, how can I document the params into the api explorer?
|
||
do I need a reference link to the class?
|
||
or can I comment in the class and have it extrapolated?
|
||
|
||
todo: going to need some default views for certain lists that come with AyaNova automatically (even if migrating)
|
||
some lists may need a list of all but also a list of all relevant items only (part inventory?)
|
||
Views that supply common tasks or functionality that was in v7 in another way
|
||
perhaps need a case to consolidate that under or maybe add the views during development?
|
||
|
||
todo: schema check appears to not count constraints but they are very important and need to be accounted for
|
||
also not checking for presence of stored procedures which are also important
|
||
add these two things as checks
|
||
|
||
todo: customer popup notes need to pop pop pop, forgot to code for that before
|
||
It's been requested for a couple of other places as well so I need a re-usable solution for this
|
||
maybe it requires dismissal rather than what I was thinking of which is a self closing alert as people may want to read it for a while.
|
||
However, I also find that incredibly annoying but I guess that's the point :)
|
||
|
||
todo: vendor add popup notes and implement on form
|
||
case 3300
|
||
|
||
todo: v8migrate should handle UnitModel without a vendor as that's permitted in v7 and it's not required in v8 either
|
||
Currently it just bombs and errors that it's required
|
||
|
||
todo: v8migrate unitmodel again, it's bombing if Number is missing on source as it's required in dest but not source
|
||
No idea, maybe make a number or use a timestamp or something?
|
||
|
||
todo: many customer service request translations keys are not translated:
|
||
"CustomerServiceRequestDetails": "Details",
|
||
"CustomerServiceRequestEventCreated": "Customer service request - New",
|
||
"CustomerServiceRequestEventCreatedUpdated": "Solicitud de servicio del cliente - nuevo / actualizado",
|
||
"CustomerServiceRequestList": "Solicitudes de servicio al cliente",
|
||
"CustomerServiceRequestOnsite": "En el lugar",
|
||
"CustomerServiceRequestParts": "Piezas",
|
||
"CustomerServiceRequestPreferredTechs": "Usuarios programables solicitados",
|
||
"CustomerServiceRequestPriority": "Prioridad",
|
||
"CustomerServiceRequestReject": "Reject service request",
|
||
"CustomerServiceRequestRequestedBy": "Requested by",
|
||
"CustomerServiceRequestStatus": "Status",
|
||
"CustomerServiceRequestTitle": "Title",
|
||
"CustomerServiceRequestWorkOrderItems": "Elementos del servicio solicitado",
|
||
"CustomerServiceRequestItemServiceToBePerformed": "Resumen del servicio a realizar",
|
||
"CustomerServiceRequestItemUnitID": "Unidad",
|
||
"CustomerServiceRequestPriorityASAP": "ASAP",
|
||
"CustomerServiceRequestPriorityEmergency": "Emergency",
|
||
"CustomerServiceRequestPriorityNotUrgent": "Not urgent",
|
||
"CustomerServiceRequestStatusAccepted": "Accepted",
|
||
"CustomerServiceRequestStatusClosed": "Closed",
|
||
"CustomerServiceRequestStatusDeclined": "Declined",
|
||
"CustomerServiceRequestStatusOpen": "Open",
|
||
|
||
todo: Date input shows higher than other components in forms
|
||
date only input read only format see CSR form created field
|
||
|
||
todo: 2fa is going to be an absolute must have pretty soon, look into what's involved again
|
||
|
||
todo: if a menu item has no icon, can it be shown to the left and exclude the space taken up by the icon?
|
||
see CSR form for example
|
||
|
||
todo: test errors on widget form for all controls
|
||
Have a way of telling the server on an update to return all the errors for all the fields possible as well as server generalerror
|
||
this way can see at a glance that all the controls are properly displaying their errrors
|
||
|
||
todo: consider that a picklist could come in separate versions that are most appropriate to their area
|
||
so a PO might show a different part list than a wo etc
|
||
not sure if sustainable as the system just expects one picklist per ayatype, but it could be tied into the variant or
|
||
maybe needs additional hint
|
||
|
||
todo: all picklists of objects htat have tags should by default include tags as the last field
|
||
this is to support choosing by tag as the feature isn't very useful if you can't see the tags that come back
|
||
|
||
|
||
todo: tag search in picklist, does it support more than one tag? I forget
|
||
no, no it doesn't. Hmmm... fuck
|
||
maybe they can enter unlimited tags as long as they have a ..before each one?
|
||
Users may need to "triangulate" on to an item by multiple tags
|
||
|
||
todo: clicking into a decimal field with zero in it already and then clicking out causes the record to be dirty
|
||
see tax-code for example
|
||
|
||
todo: figure out the datalistview form slowness when typing into the name field, maybe there are extraneous elements or something, it's important because it's oft-used
|
||
come to think of it, the form custom is plenty fast, what is different about the grid datalist view customization that slows it so much
|
||
also it's only noticeably slow in the name entry I think?
|
||
|
||
todo: document "variants" for picklists somewhere in the API docs
|
||
UserPickList inside, outside
|
||
UnitPickList customerid:333
|
||
|
||
todo: v8migrate could be dangerous with a non-empty Database
|
||
should it make user erase it from v8 end first?
|
||
Show more skulls and crossbones?
|
||
|
||
todo: NEXT DEPLOY TO DEVOPS attach a photo from phone, no error just does nothing
|
||
worked here locally latest build
|
||
retest on server after next deploy
|
||
|
||
todo: test v8migrate on big shitty database
|
||
Joyce may have requested a copy from Scott see if it can export to my server here from her test station with latest v8 migrate
|
||
|
||
todo: search form object list add service bank
|
||
|
||
TODO: //MIGRATE_OUTSTANDING comment tag
|
||
search for this comment tag as it will contain items that could not be done until other items were migrated first
|
||
The tag will contain the description for each
|
||
|
||
todo: Attachments button should indicate attachments:
|
||
Flags hasattachments status visually, do it!
|
||
(Says add attachment when none)
|
||
|
||
todo: actual customer reports so can figure out datalist for bringing other names in
|
||
I'm thinking an alternate mode for reporting where there are more defined links in the list to fetch names?
|
||
|
||
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
|
||
............................................................
|
||
|
||
|
||
|
||
CURRENTLY DOING: PartByWarehouseInventory NEXT UP: Controller routes, DataList etc
|
||
todo: datalist for raw inventory
|
||
EDIT form for partinventory item openobjecthyandler should open up to event log history of entry, not entry form since it is not editable anyway
|
||
todo: find a way to do a stock picking list format and expose in UI
|
||
|
||
UseInventory global setting, what to do about that
|
||
my initial thought is get rid of it and just default to always using inventory but inventory can't go negative so it would need to
|
||
adjust automatically or something. Maybe a new part could have an initial inventory created for it?
|
||
Not sure but needs some thought early here
|
||
See what v7 used to do about it
|
||
|
||
|
||
Inventory related objects that need to be ported:
|
||
XPart
|
||
XPartSerial
|
||
XPartWarehouse
|
||
PartInventory (was "PartByWarehouseInventory")
|
||
transformed into a inventory transaction ledger as per case 3847
|
||
PartRestock
|
||
contains partid/warehouseid/minimumstock level
|
||
PartInventoryAdjustment
|
||
XPartAssembly
|
||
|
||
PurchaseOrder
|
||
WorkorderItemPart
|
||
WorkorderItemPartRequest
|
||
|
||
|
||
|
||
|
||
|
||
PURCHASE ORDER:
|
||
# QUESTION: STATUS - what is it really for and can it be simplified / more flexible as we are moving towards *less* tight control over inventory?
|
||
Do we even need it at all?
|
||
|
||
It *appears* that in fact there is only really two status of relevance Ordered or NotOrdered and that's only to lock the UI really, the rest is maybe just for user viewing?
|
||
yes, this is the case, nothing references status except for the UI to lock or unlock fields and in that case really only open or > than open are relevant for that
|
||
the poreceipt uses it to find things to receive against but now that is integrated into the PO no need for that anymore. Hmmm...
|
||
The question is now does the user get some value from seeing the various status? and can that be solved by other means because the status induces fuckery for the user and the UI is uglified
|
||
|
||
The STATUS in v7 was used to:
|
||
drive the selection list for a po to be received (ordered not closed available)
|
||
lock the PO to prevent changes inappropriate to that PO Status:
|
||
OpenNotYetOrdered - new po, can edit anything
|
||
On order - can only change most header fields but not the items themselves from this status and higher as they are ordered and considered locked
|
||
Open partially recieved - can change nothing in any field but can click on "change closed status" to set it closed from menu
|
||
closed fully received can change nothing
|
||
closed partially received can change nothing
|
||
closed nothing received can change nothing
|
||
And from the code notes of v7:
|
||
/// If a P.O. status is currently:
|
||
/// ClosedFullReceived - can not be changed to anything
|
||
/// Any status beyond OpenNotYetOrdered can not be
|
||
/// changed back to OpenNotYetOrdered. I.E. once a P.O. is
|
||
/// OnOrder of some kind it can not be taken back to OpenNotYetOrdered
|
||
/// This ensures Purchase orders follow standard business practices for inventory control.
|
||
Indicate to the user where it's at so they know if it needs attention or not
|
||
|
||
V8 status:
|
||
PO STATES
|
||
New can edit anything because it hasn't yet been ordered
|
||
Ordered
|
||
in v7 can not change the stuff ordered substantially because it's already been ordered
|
||
But then changes inevitably occur and there are some cases related to this, i.e. price changes, item is not available, item has changed to a different item entirely adn will be sent instead etc
|
||
so the user actually from time to time *will* need to change these items and there are cases asking to do this.
|
||
Closed / completed / done, no more anything to do with it, history, doesn't need to be in top of queue or dealt with anymore
|
||
|
||
PO ITEMS STATES
|
||
new, on order - can still be changed as it isn't affecting inventory
|
||
received - can not be changed, it has affected inventory, would need to back out to un-affect inventory to really work now
|
||
Also, if it was used on a workorder or something you really can't back out of that after the fact
|
||
|
||
Maximum flexibility would be to allow any edit any time regardless and the only thing locked is things that are sold already or used on a workorder already which can't be reversed easily?
|
||
Though there is nothing to control here except inventory, the idea of locking the PO was just to ensure there was no changes from what was ordered to what will be received however that seems to be not reality and changes after order happen all the time
|
||
|
||
|
||
#QUESTION: why do wokorders care about po's and vice versa, completely seperate operations / things? Can they be completely disconnected?
|
||
PO / REQUEST / WO links
|
||
Do we need these? Does the user ever really need to drill into the workorder from teh PO? Vice versa? Doesn't this only matter up until it's fulfilled on either side one way or another?
|
||
The links mean we have stickiness issues with just allowing users to edit things at will so detracts from flexibility desired.
|
||
|
||
|
||
PART REQUESTS:
|
||
# QUESTION: can it be untied from po once it's fulfilled?
|
||
|
||
|
||
#TENTATIVE CHANGE IDEAS FOR INVENTORY
|
||
PO STATUS
|
||
Keep status but PO itself and it's items are never locked until received. If the status has been ordered then maybe a warning on save if changes made to anything that used to be locked in v7 "This po has been ordered, are you sure?"
|
||
except, why have a status at all then other than for user to see it? Maybe that's the point and in that case just let the user set the status to whatever they want with a select control
|
||
If user wants to delete or change an item that was received, since it's in it's own UI form it will prompt "Are you sure you want to reverse this inventory transaction?" and then adjust
|
||
|
||
|
||
------------------------------------------
|
||
|
||
|
||
|
||
EACH OBJECT DEV CYCLE:
|
||
FIRST
|
||
Check cases, make sure not changing the object fundamentally, many v7 objects are going to change for cases (particularly inventory related)
|
||
BACK
|
||
AyaType and associated code
|
||
BizRoles
|
||
Model and Database Schema and AyContext
|
||
DbUtil EraseAllData method
|
||
Update function PUBLIC.AYGETNAME in aySchema for new type
|
||
Biz object and all supported interfaces (searchable, exportable etc)
|
||
Biz Object SEARCH Index / getsearchresult code add unique text fields
|
||
Business rules port from v7 and new ones
|
||
Notification code if applicable
|
||
Controller routes and associated code
|
||
Translation keys
|
||
AyaFormFieldDefinitions for object if it's got a customizable form
|
||
DataList if applicable (be minimal with the default fields)
|
||
Picklist
|
||
Seeder generate samples
|
||
If anything needs to be changed down the road then flag it in comment with //MIGRATE_OUTSTANDING
|
||
FRONT
|
||
AyaType / rights
|
||
front route
|
||
List form
|
||
Edit form (## TEST ALL INPUTS ON EDIT FORM, DON"T ASSSUME THEY WORK)
|
||
|
||
Add to smoke test
|
||
DOCS (at back but with front links, maybe not fleshed out just placeholder ok for now)
|
||
REPORTING
|
||
Reportable
|
||
DASHBOARD
|
||
Add widget if dashboardable https://docs.google.com/document/d/1cEesyryhM0zYkH0PEswiuOezUTA_Nv5Xn3jfBczdQmk/edit
|
||
IMPORT
|
||
imports and flows through to new front end viewable and searchable and printable etc
|
||
|
||
|
||
|
||
## OBJECT ORDER
|
||
Preliminary order to get the ball rolling, these are the easiest starting point:
|
||
|
||
Contract
|
||
big one, tons of cases, will likely be implemented then need tweaking until it's right but the cases are all gold Jerry, gold!
|
||
|
||
|
||
Inventory (see servicebank and below bit for inspo)
|
||
Xparts
|
||
warehouse
|
||
PartInventory
|
||
po
|
||
poreceipt
|
||
adjustments
|
||
User
|
||
Fixup once have vendor, ho, client etc as it depends on those
|
||
WorkorderStatus
|
||
no dependencies, possibly many cases, read over carefully before implementing
|
||
|
||
...others tbd...
|
||
|
||
Workorder
|
||
When do this need to go back and do a bunch of //MIGRATE_OUTSTANDING
|
||
i.e. show all
|
||
todo: Consider adding latitude / longitude to wo, quote, pm objects
|
||
rate split
|
||
can copy over from the unit or customer or set themselves
|
||
and can always hide
|
||
means wo could be scheduled for ad-hoc locations and serviced that way, i.e. a truck parked on the side of the highway etc
|
||
|
||
INVENTORY AND BALANCE STUFF
|
||
Best implemented as a stored procedure?
|
||
this example is exactly a bank balance
|
||
https://www.postgresqltutorial.com/postgresql-create-procedure/
|
||
|
||
|
||
# V7 objects now TAGS, the following objects are imported as tags and suffixed with a period and then short versions of the object type in the tag name
|
||
- Region
|
||
- UnitModelCategory
|
||
- UnitServiceType
|
||
- WorkorderItemType
|
||
- ClientGroup
|
||
- WorkorderCategory
|
||
- PartCategory
|
||
- DispatchZone
|
||
- ScheduleableUserGroup
|
||
- ClientNoteType
|
||
- VendorType ## LATE ADDITION
|
||
|
||
|
||
## v7 DB DEPENDENCIES
|
||
object
|
||
depends on
|
||
|
||
AssignedDoc * Already handled automatically by v8 migrate
|
||
none
|
||
|
||
xaclient
|
||
adispatchzone - TAG
|
||
aheadoffice
|
||
aworkorder
|
||
|
||
xaclientgroup - TAG
|
||
none
|
||
|
||
xaclientnote
|
||
aclientnotetype - TAG
|
||
aclient
|
||
|
||
xaclientnotetype - TAG
|
||
none
|
||
|
||
DEPRECATED - aclientnotifyevent -
|
||
none
|
||
|
||
aclientservicerequest
|
||
aworkorderitem
|
||
|
||
DEPRECATED - acontact -
|
||
acontacttitle
|
||
|
||
acontract
|
||
aregion - TAG
|
||
|
||
acontractrate
|
||
acontract
|
||
arate
|
||
|
||
adispatchzone - TAG
|
||
aregion - TAG
|
||
|
||
DEPRECATED / HANDLED AUTOMATICALLY BY IMPORT afile
|
||
none
|
||
|
||
xaglobal
|
||
ataxcode
|
||
aworkorder
|
||
aworkorderstatus
|
||
|
||
xaglobalex
|
||
none
|
||
|
||
xaheadoffice
|
||
aclientgroup - tag
|
||
acontract
|
||
|
||
aintegration
|
||
none
|
||
|
||
aintegrationmap
|
||
aintegration
|
||
|
||
Xaloanitem
|
||
aregion - TAG
|
||
aworkorderitemloan
|
||
|
||
xamemo
|
||
auser
|
||
|
||
DEPRECATED - anotify*
|
||
lots of tables, but it's all obsolete and won't be ported
|
||
|
||
HANDLED BY IMPORT - aobjectcustomfield
|
||
(defines custom fields, is part of base import already, nothing special required here)
|
||
|
||
apart
|
||
apartassembly
|
||
apartcategory - TAG
|
||
aunitofmeasure
|
||
avendor
|
||
|
||
apartassembly
|
||
none
|
||
|
||
apartbywarehouseinventory
|
||
apart
|
||
apartwarehouse
|
||
|
||
apartcategory - TAG
|
||
none
|
||
|
||
apartinventoryadjustment
|
||
none
|
||
|
||
apartinventoryadjustmentitem
|
||
apart
|
||
apartinventoryadjustment
|
||
apartwarehouse
|
||
|
||
apartserial
|
||
apartinventoryadjustmentitem
|
||
apurchaseorderreceiptitem
|
||
aworkorderitempart
|
||
|
||
apartwarehouse
|
||
aregion - TAG
|
||
|
||
xapriority
|
||
none
|
||
|
||
xaproject
|
||
aregion - TAG
|
||
auser
|
||
|
||
apurchaseorder
|
||
aproject
|
||
avendor
|
||
|
||
apurchaseorderitem
|
||
apart
|
||
apartwarehouse
|
||
apurchaseorder
|
||
ataxcode
|
||
aworkorderitempartrequest
|
||
|
||
apurchaseorderreceipt
|
||
avendor
|
||
|
||
apurchaseorderreceiptitem
|
||
apart
|
||
apurchaseorder
|
||
apurchaseorderitem
|
||
apurchaseorderreceipt
|
||
|
||
xarate
|
||
aclientgroup - tag
|
||
arateunitchargedescription - DEPRECATED per case 3432
|
||
aregion - TAG
|
||
|
||
DEPRECATED case 3432 - arateunitchargedescription
|
||
none
|
||
|
||
xaregion - TAG
|
||
aworkorderstatus ?! WTF?
|
||
|
||
xregionnotifystat ?wtf is this?
|
||
aregion - TAG
|
||
|
||
REPLACED NEW FORMAT - areport
|
||
aregion - TAG
|
||
|
||
xaScheduleableUserGroup - TAG
|
||
none
|
||
|
||
xascheduleableusergroupuser
|
||
aScheduleableUserGroup - TAG
|
||
auser
|
||
|
||
aschedulemarker (now "Reminder")
|
||
none ?must be at least user in there...weird
|
||
|
||
DEPRECATED - asecuritygroup (nope)
|
||
none
|
||
|
||
xaservicebank
|
||
none
|
||
|
||
atask
|
||
none
|
||
|
||
ataskgroup
|
||
none
|
||
|
||
ataskgrouptask
|
||
atask
|
||
ataskgroup
|
||
|
||
xataxcode
|
||
none
|
||
|
||
aui* (these are all v7 UI saved settings that are not applicable to v8)
|
||
|
||
xaunit
|
||
aclient
|
||
aunitmodel
|
||
|
||
xaunitmeterreading
|
||
aworkorderitem
|
||
|
||
xaunitmodel
|
||
aunitmodelcategory - TAG
|
||
avendor
|
||
|
||
xaunitmodelcategory - TAG
|
||
none
|
||
|
||
DEPRECATED NO MORE - aunitofmeasure
|
||
none
|
||
|
||
xaunitservicetype - TAG
|
||
none
|
||
|
||
xauser
|
||
adispatchzone - TAG
|
||
aheadoffice
|
||
apartwarehouse
|
||
asecuritygroup
|
||
avendor
|
||
aworkorder
|
||
|
||
xausercertifcation* (these are now tags and already rolled into v8 migrate tool)
|
||
|
||
xausermru DEPRECATED
|
||
xauserright DEPRECATED
|
||
|
||
xauserskill* (now tags and already accounted for in v8 migrate)
|
||
|
||
xavendor
|
||
none
|
||
|
||
xawikipage* (already accounted for in v8 migrate code, object by object will export)
|
||
|
||
aworkorder (new structure, some of these are no longer joined due to seperation of wo types in v8)
|
||
aproject
|
||
aregion - TAG
|
||
aworkordercategory - TAG
|
||
aworkorderpreventivemaintenance
|
||
aworkorderquote
|
||
|
||
xaworkordercategory - TAG
|
||
none
|
||
|
||
aworkorderitem
|
||
apriority
|
||
aunit
|
||
aunitservicetype - TAG
|
||
aworkorderitemtype - TAG
|
||
aworkorderstatus
|
||
|
||
aworkorderitemlabor
|
||
arate
|
||
aservicebank
|
||
ataxcode
|
||
aworkorderitem
|
||
|
||
aworkorderitemloan
|
||
aloanitem
|
||
ataxcode
|
||
aworkorderitem
|
||
|
||
aworkorderitemmiscexpense
|
||
ataxcode
|
||
aworkorderitem
|
||
|
||
aworkorderitemoutsideservice
|
||
avendor
|
||
aworkorderitem
|
||
|
||
aworkorderitempart
|
||
apart
|
||
apartserial
|
||
apartwarehouse
|
||
ataxcode
|
||
aworkorderitem
|
||
|
||
aworkorderitempartrequest
|
||
apart
|
||
apartwarehouse
|
||
apurchaseorderitem
|
||
aworkorderitem
|
||
|
||
aworkorderitemscheduleduser
|
||
arate
|
||
aworkorderitem
|
||
|
||
aworkorderitemtask
|
||
atask
|
||
ataskgroup
|
||
aworkorderitem
|
||
|
||
aworkorderitemtravel
|
||
arate
|
||
aservicebank
|
||
ataxcode
|
||
aworkorderitem
|
||
|
||
xaworkorderitemtype - TAG
|
||
none
|
||
|
||
aworkorderpreventivemaintenance
|
||
aworkorder
|
||
aworkorderstatus
|
||
|
||
aworkorderquote
|
||
aworkorder
|
||
|
||
aworkorderservice
|
||
aworkorderpreventivemaintenance
|
||
aworkorderstatus
|
||
|
||
xaworkorderstatus
|
||
none
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
//---------------------------------------------------------------------------------------------
|
||
NoType = 0,
|
||
Global = 1,
|
||
[CoreBizObject]
|
||
Widget = 2,
|
||
[CoreBizObject]
|
||
User = 3,
|
||
ServerState = 4,
|
||
License = 5,
|
||
LogFile = 6,
|
||
PickListTemplate = 7,
|
||
[CoreBizObject]
|
||
Customer = 8,
|
||
ServerJob = 9,
|
||
[CoreBizObject]
|
||
Contract = 10,
|
||
TrialSeeder = 11,
|
||
ServerMetrics = 12,
|
||
Translation = 13,
|
||
UserOptions = 14,
|
||
[CoreBizObject]
|
||
HeadOffice = 15,
|
||
[CoreBizObject]
|
||
LoanUnit = 16,
|
||
FileAttachment = 17,
|
||
DataListView = 18,
|
||
FormCustom = 19,
|
||
[CoreBizObject]
|
||
Part = 20,
|
||
[CoreBizObject]
|
||
PM = 21,
|
||
[CoreBizObject]
|
||
PMItem = 22,
|
||
[CoreBizObject]
|
||
PMTemplate = 23,
|
||
[CoreBizObject]
|
||
PMTemplateItem = 24,
|
||
[CoreBizObject]
|
||
Project = 25,
|
||
[CoreBizObject]
|
||
PurchaseOrder = 26,
|
||
[CoreBizObject]
|
||
Quote = 27,
|
||
[CoreBizObject]
|
||
QuoteItem = 28,
|
||
[CoreBizObject]
|
||
QuoteTemplate = 29,
|
||
[CoreBizObject]
|
||
QuoteTemplateItem = 30,
|
||
[CoreBizObject]
|
||
Unit = 31,
|
||
[CoreBizObject]
|
||
UnitModel = 32,
|
||
[CoreBizObject]
|
||
Vendor = 33,
|
||
//--- WorkOrder
|
||
[CoreBizObject]
|
||
WorkOrder = 34,
|
||
[CoreBizObject]
|
||
WorkOrderItem = 35,
|
||
[CoreBizObject]
|
||
WorkOrderItemExpense = 36,
|
||
[CoreBizObject]
|
||
WorkOrderItemLabor = 37,
|
||
[CoreBizObject]
|
||
WorkOrderItemLoan = 38,
|
||
[CoreBizObject]
|
||
WorkOrderItemPart = 39,
|
||
[CoreBizObject]
|
||
WorkOrderItemPartRequest = 40,
|
||
[CoreBizObject]
|
||
WorkOrderItemScheduledUser = 41,
|
||
[CoreBizObject]
|
||
WorkOrderItemTask = 42,
|
||
[CoreBizObject]
|
||
WorkOrderItemTravel = 43,
|
||
[CoreBizObject]
|
||
WorkOrderItemUnit = 44,
|
||
//---
|
||
[CoreBizObject]
|
||
WorkOrderTemplate = 45,
|
||
[CoreBizObject]
|
||
WorkOrderTemplateItem = 46,
|
||
GlobalOps = 47,
|
||
BizMetrics = 48,
|
||
Backup = 49,
|
||
Notification = 50,
|
||
NotifySubscription = 51,
|
||
Reminder = 52,
|
||
UnitMeterReading = 53,
|
||
CustomerServiceRequest = 54,
|
||
ServiceBank = 55,
|
||
OpsNotificationSettings = 56,
|
||
Report = 57,
|
||
DashboardView=58
|
||
|
||
[Description("LT:O.Nothing")] Nothing = 0,
|
||
[Description("LT:O.Global")] Global = 1,
|
||
[Description("LT:O.Region")] Region = 2,
|
||
[Description("LT:O.Client")] Client = 3,
|
||
[Description("LT:O.Vendor")] Vendor = 4,
|
||
[Description("LT:O.HeadOffice")] HeadOffice = 5,
|
||
[Description("LT:O.RentalUnit")] RentalUnit = 6,
|
||
[Description("LT:O.Unit")] Unit = 7,
|
||
[Description("LT:O.UnitModel")] UnitModel = 8,
|
||
[Description("LT:O.Workorder")] Workorder = 9,
|
||
[Description("LT:O.WorkorderItem")] WorkorderItem = 10,
|
||
[Description("LT:O.UserSkillAssigned")] UserSkillAssigned = 11,
|
||
[Description("LT:O.UserCertificationAssigned")] UserCertificationAssigned = 12,
|
||
[Description("LT:O.User")] User = 13,
|
||
[Description("LT:O.Part")] Part = 14,
|
||
[Description("LT:O.LoanItem")] LoanItem = 15,
|
||
[Description("LT:O.DispatchZone")] DispatchZone = 16,
|
||
[Description("LT:O.Rate")] Rate = 17,
|
||
[Description("LT:O.Contract")] Contract = 18,
|
||
[Description("LT:O.Project")] Project = 19,
|
||
[Description("LT:O.PurchaseOrder")] PurchaseOrder = 20,
|
||
[Description("LT:O.ClientGroup")] ClientGroup = 21,
|
||
[Description("LT:O.WorkorderCategory")] WorkorderCategory = 22,
|
||
[Description("LT:O.WorkorderItemScheduledUser")] WorkorderItemScheduledUser = 23,
|
||
[Description("LT:O.WorkorderItemOutsideService")] WorkorderItemOutsideService = 24,
|
||
[Description("LT:O.WorkorderItemPart")] WorkorderItemPart = 25,
|
||
[Description("LT:O.WorkorderItemLabor")] WorkorderItemLabor = 26,
|
||
[Description("LT:O.WorkorderItemTravel")] WorkorderItemTravel = 27,
|
||
[Description("LT:O.WorkorderItemMiscExpense")] WorkorderItemMiscExpense = 28,
|
||
[Description("LT:O.WorkorderItemPartRequest")] WorkorderItemPartRequest = 29,
|
||
[Description("LT:O.WorkorderItemLoan")] WorkorderItemLoan = 30,
|
||
[Description("LT:O.ClientNote")] ClientNote = 31,
|
||
[Description("LT:O.ServiceBank")] ServiceBank = 32,
|
||
[Description("LT:O.WorkorderQuote")] WorkorderQuote = 33,
|
||
[Description("LT:O.WorkorderService")] WorkorderService = 34,
|
||
[Description("LT:O.AssignedDoc")] AssignedDocument = 35,
|
||
[Description("LT:O.PartWarehouse")] PartWarehouse = 36,
|
||
[Description("LT:O.UnitMeterReading")] UnitMeterReading = 37,
|
||
[Description("LT:O.UnitModelCategory")] UnitModelCategory = 38,
|
||
[Description("LT:O.Locale")] Locale = 39,
|
||
[Description("LT:O.SearchResult")] SearchResult = 40,
|
||
[Description("LT:O.WorkorderItemType")] WorkorderItemType = 41,
|
||
[Description("LT:O.UnitServiceType")] UnitServiceType = 42,
|
||
[Description("LT:O.PartAssembly")] PartAssembly = 43,
|
||
[Description("LT:O.AyaFile")] AyaFile = 44,//case 73
|
||
[Description("LT:O.Contact")] Contact = 45,
|
||
[Description("LT:O.ContactPhone")] ContactPhone = 46,
|
||
[Description("LT:O.WorkorderPreventiveMaintenance")] WorkorderPreventiveMaintenance = 47,
|
||
[Description("LT:O.TaskGroup")] TaskGroup = 48,
|
||
[Description("LT:O.ScheduleMarker")] ScheduleMarker = 49,
|
||
[Description("LT:O.ClientServiceRequest")] ClientServiceRequest = 50,
|
||
[Description("LT:O.ScheduleableUserGroup")] ScheduleableUserGroup = 51,
|
||
[Description("LT:O.Task")] Task = 52,
|
||
[Description("LT:O.Memo")] Memo = 53,
|
||
[Description("LT:O.PartCategory")] PartCategory=54,
|
||
[Description("LT:O.UnitOfMeasure")] UnitOfMeasure=55,
|
||
[Description("LT:O.TaxCode")] TaxCode=56,
|
||
[Description("LT:O.PartSerial")] PartSerial = 57,
|
||
[Description("LT:O.PartInventoryAdjustment")] PartInventoryAdjustment = 58,
|
||
[Description("LT:O.PartInventoryAdjustmentItem")] PartInventoryAdjustmentItem = 59,
|
||
[Description("LT:O.Priority")] Priority=60,
|
||
[Description("LT:O.UserSkill")] UserSkill=61,
|
||
[Description("LT:O.WorkorderStatus")] WorkorderStatus=62,
|
||
[Description("LT:O.UserCertification")] UserCertification=63,
|
||
[Description("LT:O.ClientNoteType")] ClientNoteType=64,
|
||
[Description("LT:O.SecurityGroup")] SecurityGroup=65,
|
||
[Description("LT:O.PurchaseOrderReceiptItem")] PurchaseOrderReceiptItem=66,
|
||
[Description("LT:O.PartByWarehouseInventory")] PartByWarehouseInventory=67,
|
||
[Description("LT:O.Report")] Report=68,
|
||
[Description("LT:O.WorkorderQuoteTemplate")]
|
||
WorkorderQuoteTemplate = 69,
|
||
[Description("LT:O.WorkorderServiceTemplate")]
|
||
WorkorderServiceTemplate = 70,
|
||
[Description("LT:O.WorkorderPreventiveMaintenanceTemplate")]
|
||
WorkorderPreventiveMaintenanceTemplate = 71,
|
||
[Description("LT:O.WikiPage")]//case 73
|
||
WikiPage = 72,
|
||
[Description("LT:O.GridFilter")]//case 941
|
||
GridFilter = 73,
|
||
[Description("LT:O.NotifySubscription")]//case 941
|
||
NotifySubscription = 74,
|
||
[Description("LT:O.PurchaseOrderReceipt")]//case 941
|
||
PurchaseOrderReceipt = 75,
|
||
[Description("LT:O.Notification")]//case 1172
|
||
Notification = 76,
|
||
[Description("LT:UI.Go.Schedule")]//case 812
|
||
Schedule = 77,
|
||
[Description("LT:O.WorkorderItemTask")]//case 1317
|
||
WorkorderItemTask = 78,
|
||
[Description("LT:O.WorkorderItemUnit")]//case 1317
|
||
WorkorderItemUnit = 79,
|
||
[Description("LT:ScheduleMarker.Label.FollowUp")]//case 1975
|
||
FollowUp = 80
|
||
|
||
|
||
------------------------------------------------------------------------------------------
|
||
|
||
POST "REALITY" OR IN PARALLEL "REALITY" related items:
|
||
|
||
todo: CYPRESS TEST DATE / TIME / DATE_TIME controls switched back to vuetify ones
|
||
widget entry form test rewrite
|
||
https://github.com/cypress-io/cypress/issues/7404
|
||
https://github.com/vuetifyjs/vuetify/issues/10988#issuecomment-726089949
|
||
|
||
TODO: //MIGRATE_OUTSTANDING comment tag
|
||
search for this comment tag as it will contain items that could not be done until other items were migrated first
|
||
The tag will contain the description for each
|
||
|
||
todo: Schedule form
|
||
- This one is big but requires the data to be there so as soon as implement enough things that are scheduleable then do this
|
||
- printing / reporting schedule? Do-able?
|
||
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/729
|
||
|
||
|
||
todo: can beta test at this point
|
||
See below, specific ideas about public beta test (User accounts not seperate installs maybe)
|
||
post installer, enlist trial users get feedback, don't get too down when they shit all over it as they will undoubtedly :)
|
||
remember, it's for the new customers primarily, new customers = new $$
|
||
|
||
todo: Document in user manual all form controls with instruction on how to use the various controls etc
|
||
- "Anatomy of a AyaNova Form"
|
||
|
||
WORKORDER UI
|
||
todo: Investigate Workorder structure and datagrid see case https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3768
|
||
Likely that workorder grids inside will not be full blown custom datagrid I wrote but just a vanilla v-data-table control since there is likely no need for the full customization shit
|
||
todo: workorder UI layout stuff (TTM!! Don't re-invent the wheel!)
|
||
There's been a lot of ideas about wo floating around and considered, but at the end of the day what I have works so maybe try to meld
|
||
into what I have the new concepts and see what comes out. Support a rich wo UI on big screens and scroll around UI on phone maybe.
|
||
some notes:
|
||
Workorder UI good ideas here: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3475
|
||
Basically (based on RI) it boils down to don't make the user go up to the workorder item level when they can go sideways directly to an alternate child of woitem
|
||
i.e. going from parts to labor shouldn't require going up a level
|
||
All workorder in one document and just really really tall? (people bitch about RI requiring too many navigation steps to get to shit)
|
||
Header and items in one document then bottom in seperate pages?
|
||
Is it going to be far easier to code this bitch if I have all the workorder data at hand or..?
|
||
How does WBI handle all this because it's kind of the poster child for RAVEN
|
||
Workorder is one of those things that may require different views for phone and tablet and laptop etc
|
||
Kind of like two views, tiny phone and anything larger
|
||
On a PC people will want and expect it to look as much like v7 workorder as possible, maybe that's still a valid layout
|
||
just tweaked to work better as a web app a bit but theoretically I could almost duplicate that layout with the tools I have
|
||
|
||
|
||
Consider UI in this as well, will need to decide at least what is visible when
|
||
Workorder UI good ideas here: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3475
|
||
How to add items, like new woitem?
|
||
send to server get back new object?
|
||
lots of biz rules and stuff need to happen, want to minimize load at client
|
||
but lots of data back and forth is not ideal
|
||
maybe request a woitem and get it back?
|
||
what exactly needs to be processed in the wo when items are added / removed?
|
||
math / totalling?
|
||
simple calcs sb client doable
|
||
this will drive what has to happen.
|
||
Need to go over all wo features and factor them into this decision properly
|
||
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?
|
||
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
|
||
Customer is then who exactly because it's fundamental to a lot of wo functionality?
|
||
from a biz perspective isn't it like you are your own customer when you service your own equipment that you loan out?
|
||
Does Serial field need to be numeric, could it be text instead?
|
||
prompted by case 3428 saying that it's hard to deal with constant conversion to text for UI etc
|
||
plus, I'm thinking it opens door to textual scheme like appending -A or whatever to a wo.
|
||
or, is that a display issue?
|
||
Calling something "serial" implies it's unique but it isn't, maybe I should call it "number" instead or "ID" or something?
|
||
INFO: did a test workorder with ALL fields filled out heavily and one woitem, exported from db entire graph based on detailed report so every line was every item repeated
|
||
still only 84kb and it's a lot bigger than any typical wo in v8 would be as it will be far more efficient without having to repeat lines flatly
|
||
so I think size of object is a non-issue really from a practical standpoint.
|
||
|
||
|
||
UI
|
||
|
||
idea: UI reflects tentativeness state of object:
|
||
The UI doesn't imply something is done by changing it fully until the save is completed.
|
||
This serves two purposes:
|
||
1) user knows at a glance what isn't saved yet and will know it's waiting for save clearly, hopefully leading them to save more often,
|
||
2) client doesn't need to track invisible shit behind the scenes, can more easily do patch updates right off UI source
|
||
|
||
e.g.:
|
||
if deleted a row in parts, that row doesn't disappear but rather shows crossed out, maybe grayed out but still there until save to indicate it's tentative status
|
||
if added a row, shows green or something or bold or asterisk, (can style with css based on state) until saved
|
||
problems:
|
||
how to handle regular fields that are changed (that's a lot of field data to track for changes)?
|
||
Maybe client keeps a virgin copy of the original wo for comparison
|
||
periodically does a compare and flags differences on updates?
|
||
(this would also help to serve as an Undo maybe?)
|
||
|
||
|
||
|
||
todo: Documentation POST "REALITY"
|
||
will already have placeholders from above
|
||
Need to think this through carefully
|
||
Need to get the critical bits in for onboarding and importing so people can get going
|
||
Most important stuff is anything non-obvious
|
||
Seems pointless to have one doc per form that just says "The name field is the name and must be unique"
|
||
maybe have that kind of stuff in the form basics and then have a doc per OBJECT instead with anything unique or interesting about the object
|
||
(and each object form has a link to formbasics so can link to the object form from UI and they get both)
|
||
Parts of it can be done post-release for sure
|
||
|
||
|
||
|
||
todo: ONGOING search for memory leaks
|
||
The 7 times system seems to work the best
|
||
Excercise item a few times to settle it in memory, take heap snapshot, force gc, take total of 3 heap snapshots forcing gc each times
|
||
Excercise item 7 times exactly, take 3 more heap snapshots forcing gc before each one
|
||
Compare snapshot 6 to snapshot 3 look for Delta 7 times items to find leak
|
||
https://developers.google.com/web/tools/chrome-devtools/memory-problems
|
||
https://nolanlawson.com/2020/02/19/fixing-memory-leaks-in-web-applications/
|
||
|
||
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
@@@@@@@@@@@@@@@ ROADMAP STAGE 7 - EXTENSIONS (was plugins)
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
|
||
Step 1: get the current active license count for all extensions so we know what we're dealing with here
|
||
Step 2: which extensions in which order and some can be left off entirely?
|
||
|
||
Plan the order of criticality for extensions
|
||
ACCOUNTING is obviously the first and foremost one and MUST be there for a lot of people to take up
|
||
MUST be done in a way to support other alternative accounting apps that are coming around now like freshbooks or whatever it's called that Joyce is using now
|
||
probably going to need a "trick" of some kind to interface with desktop accounting
|
||
i.e. a local windows app that uses the api and just copy over the qbi code
|
||
or a local server that has it's own web interface
|
||
or regular raven UI but the accounting section interfaces with a local server for local desktop qbi stuff and
|
||
the raven server interfaces with QBOnline for the QBOI stuff
|
||
|
||
based on sales, how many subscribed now
|
||
which ones are porting and which are not
|
||
Implement in order or priority
|
||
Fuck peachtree?
|
||
probably not, need to check again our install count of extensions
|
||
|
||
|
||
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
@@@@@@@@@@@@@@@ ROADMAP STAGE 8 - ONLINE EVALUATION ABILITY / INSTALLER, LICENSING, ROCKFISH SUPPORT FOR RAVEN
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
|
||
todo: setup for automated trial testing ability so can just link users
|
||
Maybe, rather than having seperate servers for testing, have it instead generate a User account on the fly for each user who wants to trial
|
||
Automatically re-create the data on a cycle of some kind
|
||
Needs warning message about being a shared instance of AyaNova so be careful what you type and also you may see things other people typed that we have no control over
|
||
|
||
todo: WINDOWS INSTALLER
|
||
Runner harness wrapper thing?
|
||
even if windows only
|
||
it could modify config since it's outside the server
|
||
check for Postgres server extant and if not automatically start the standalone postgres instance
|
||
manage postgres start and stop and configuration changes, sit in tray, run AyaNova server from there?
|
||
|
||
easy way to select command line params without resorting to editing text files for end user
|
||
initially it's an installation option, but then need to edit after the fact
|
||
Quick check of installers available still and is it still kosher to keep using INNO setup or is something better, more supported by windows etc?
|
||
Wix if want MSI (some say that's desireable)
|
||
INNO is still relevant
|
||
I don't need hardly any requirements that can't just be copy or unzip deployed so maybe don't even need an installer for now?
|
||
(zip distribution is going to be problematic with Windows file protection shit)
|
||
https://docs.microsoft.com/en-us/dotnet/core/deploying/
|
||
https://docs.microsoft.com/en-us/dotnet/core/rid-catalog
|
||
|
||
|
||
Completely packaged and installable. REady for users to install as a test as I iterate stage 7 below
|
||
All the stuff needed for someone to run it as a test without the real objects yet.
|
||
Some kind of expiring license so they can't just keep using it as fucked as it may be some might do that
|
||
I want short targetted testing only, not someone downloading and trying it out a month later, that's useless for us
|
||
This needs to be focused on what I need to get from people about testing
|
||
|
||
|
||
todo: LINUX INSTALLER
|
||
Linux users don't mind doing the manual config thing as much, they're used to it and it could just be a shell file anyway
|
||
So mainly this would be a documentation steps to install type issue
|
||
|
||
|
||
todo: DOCUMENT DOCKER
|
||
Present dockerfile maybe for docker installation with FILES folder pre-ready to build / run
|
||
Whatever docker needs
|
||
Or maybe private registry with docker images on our servers somewhere
|
||
|
||
todo: rockfish, can't do purchase for raven or view it I think
|
||
Test a whole sales process from eval to purchase and make it work
|
||
todo: rockfish, upgrade to latest bootstrap, out of date Currently
|
||
todo: rockfish, trial license fetched On date not updating? (not showing in UI)
|
||
|
||
todo: Joyce rockfish notes:
|
||
Licensing:
|
||
noticed that the field "Fetched on" is NEVER updated.
|
||
is it much to be able to see the TIME as well as the DATE, when "Requested" and when "Processed"?
|
||
There are drop down selections NEW, APPROVED, REJECTED for the (already generated) listed keys. But can not actually save to a different Status. What is the purpose of the drop down options if can not select?
|
||
|
||
|
||
|
||
|
||
todo: Discourse bootstrapping install
|
||
look over, get ideas make case steal ideas profit FTW$
|
||
https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md
|
||
//here is their standalone config yml definition for DOCKER
|
||
https://github.com/discourse/discourse_docker/blob/master/samples/standalone.yml
|
||
|
||
|
||
|
||
todo: back and forward buttons when running without browser controls in application mode?
|
||
- wait and see on this one, as it will be likely outside of any particular form so not something to be baked in early necessarily
|
||
|
||
todo: GUIDED TOUR
|
||
- This is an important feature and at least get a basic one in there for starters and initial release
|
||
- This is a replacement for the tutorials and videos in v7 a
|
||
- Need to add that auto-pilot thingy that allows for guided tours in HTML apps
|
||
- Specifically it should at least have an ONBOARDING walk through of how to move around, enter data, get help etc. Not feature specific but usage specfic.
|
||
- Later I'll add feature specfic tutorials like how to make a workorder etc
|
||
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
@@@@@@@@@@@@@@@ ROADMAP STAGE 9 - RELEASE
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
|
||
todo: ARCHIVE ALL DEPENDENCIES
|
||
Get all code for all 3rd party libs used for front and back of AyaNova 8
|
||
Need to store that in an archive somewhere just in case
|
||
Needs to be done with each release so can go back to that if necessary
|
||
Going to be big, maybe archived to all storage drives locally and burned to a dvd?
|
||
If check into the repo it will be an issue probably but you never know
|
||
|
||
TODO: CSP Policy that should be enabled at server?
|
||
I had to add per this: https://docs.telerik.com/kendo-ui/troubleshoot/content-security-policy#content-security-policy
|
||
to my csp because I kept getting errors in client end debug console mentioning csp issues
|
||
this seemed to come after I updated the client build process to do a legacy and modern build but I'm not 100% sure about that
|
||
|
||
Assuming has passed all testing
|
||
Plan pricing and sales strategy
|
||
What to do with licenses for v7 people
|
||
Another payment processor?
|
||
support bitcoin if possible as well
|
||
|
||
|
||
DONATE
|
||
Send a tip / buy a coffee link to the graphic designer who made the rabbit logo
|
||
follow the link from the docs appendix open source acknowledgements page
|
||
if we use it in release we should at least send them the small amount they get tipped
|
||
|
||
Send a tip / donate to teh favicon generator guy
|
||
https://realfavicongenerator.net/
|
||
I broke it at one point by bringing down the site while it was checking ... oops.
|
||
Used it several times and should donate
|
||
|
||
|
||
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
@@@@@@@@@@@@@@@ ROADMAP STAGE 10 - ROCKFISH / HOSTING BACKEND SELF SERVER READINESS
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
DO server allocation, rockfish revamp to drive this part (or maybe it's an alternate app)
|
||
https://blog.digitalocean.com/its-all-about-the-bandwidth-why-many-network-intensive-services-select-digitalocean-as-their-cloud/?utm_medium=email&utm_source=do_newsletter&utm_campaign=04292020
|
||
https://www.youtube.com/watch?v=zZVoo5AbANI
|
||
|
||
|
||
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
@@@@@@@@@@@@@@@ ROADMAP STAGE 11 - RELEASE SELF SERVE / HOSTING
|
||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||
Fall of 2020 hopefully
|
||
links on website for sign up
|
||
marketing can begin in earnest
|
||
|
||
NOTE: HOSTING cases are all moved to priority 2 and most have "HOSTING" in the title tags
|
||
|
||
todo: Administration - Account
|
||
Down the road will need an Account page for seeing their account status in rental SAAS situation
|
||
Nothing to do here, it's an obvious one, just delete this later, it's to percolate in brain a bit
|
||
maybe under license
|
||
|
||
PLAIN TEXT EMAILS / ONBOARDING
|
||
https://blog.palabra.io/great-onboarding-plain-text
|
||
|
||
MARKETING
|
||
Analytics alternatives to Google:
|
||
https://news.ycombinator.com/item?id=24198329
|
||
|
||
Also very nice screen shot effect:
|
||
https://umami.is/
|
||
Created by:
|
||
|
||
dom96 2 hours ago [–]
|
||
|
||
Nice! Question for you, how did you make that nice 3D image on the front page with various screenshots overlaid over each other? :)
|
||
|
||
reply
|
||
|
||
|
||
mcao 2 hours ago [–]
|
||
|
||
It's all done in Photoshop. Just take screenshots, then transform, rotate, distort them to look flat. Then add some drop shadows for a 3d look.
|
||
|
||
reply
|
||
|