admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
34887401037bf9be60bfda4c3bc2e5073bfc8dbf
raven-client/ayanova/devdocs/todo.txt
John Cardinal 3488740103
2020-07-31 21:02:47 +00:00

516 lines
33 KiB
Plaintext
Raw Blame History

@@@@@@@@@@@ ROADMAP STAGE 2:
PRIORITY - ALWAYS Lowest level stuff first, i.e. TODO at server, api route changes etc then back here in order lowest level first as affects the most stuff exponentially so best to do it early
=-=-=-=-
## CURRENT STAGE:
MODIFY USERS LIST FORM PER BELOW
MODIFY USER EDIT FORM PER BELOW
Copy and replicate to Customer users centric UI (list and edit form) within customers area of UI
todo: USER redux
# EXISTING USERS UI to be staff / contractor centric, no customer users
Change current Users list data-table to use the regular data-table
Add a User controller List route to get all non customer Users
Modify User edit form to restrict the types of Users so you can't pick customer or head office, they will be separate
#Add customer centric users in customer tree area
Copy from regular users and modify the list and edit form
Consider adding an OutsideUser controller and associated biz object copied from User but then modified for customer / ho editing listing instead
Then all the role checking shit will be easier, though the regular User needs to be modified to NOT allow "Outside" type users to be edited etc
(Validation rule actually would make this work and special GET checking to prevent fetching cross roles type of user)
Add a dedicated list object at the User controller for "Outside" users
Rights are same as Customer object so anyone who can edit customers can edit their users
Edit form with Customer / headoffice picklist that shows depending on type of User
Edit form also must have the various options taht are on UserOptions form so they can be set up for the user and we don't need a useroptions form for them
Edit form Roles control absent, instead defaults
Notification subscriptions set here as well on behalf of customer user
Can only pick user type of headoffice or Customer (radio button?)
Edit User Route / Biz to allow rights to Customer to work instead of rights to User *IF* the User in question is an Outside user
Customer User UI area accessed from Customer form for CRUD User accounts tied to customers and also for setting up Notifications for those users
this is big and needs it's own NOTIFICATION area as well
can customer control this or does the biz admin control this?
See below there's a todo block about this
todo: Customer User list form side track but relevant to this
Have to decide, do I list all users in the Existing users list form including customers?
Or, is it done via the Customer themselves?
Or is it both maybe, shit have to pick one
I can see a case for wanting to just see every user together regardless of type and another case for wanting to simplify it down to just going via the customer themselves
have to imagine the use cases and go accordingly.
My gut feeling is people would rather go via Customer page since they are likely in there via interacting with the customer in the first place, i.e. we fired Bob so take him off or we hired
Shirly so put her on or why am I not getting notifications can you test it etc
Case for the full list including customer users is really just a "it woudl be nice to see them all in one place" but they aren't like normal users and will need an alternative editing UI anyway
So My gut feeling is to do it via the Customer as a limited list, not via the regular Users page
it would have it's own edit form and own list as it would not need the full datalist treatment in theory
Plus there also needs to be a way to do subscriptions for the customer users as well which would be easier with it's own UI area completely
todo: Test server down while polling in release mode, does it recover when server starts again or...?
todo: read only version of duration, datetime, date, time, currency
todo: pick lists in forms should be sortable alphabetically *at the client end* as default but optionally turn off so for things that are a definite order not alphabetic can turn off
for example the event types and object types in notification subscription
todo: does Duplicate code really duplicate the tags?
i.e. duplicate a widget with tags, do the tags come over?
if not then need to modify the copy object code to handle tags as well
todo: PickLists based on AyaPickList at server, need one for each type, so far have widget and user only
Not sure if should just make them all or...??
Maybe when I hit a form that uses it, that's when I really need it?
todo: help links for individual extensions (does this refer to the new plugins?)? (button I guess since no menu on them)
todo: rockfish, can't do purchase for raven or view it I think
todo: rockfish, upgrade to latest bootstrap, out of date Currently
todo: rockfish, trial license fetched On date not updating? (not showing in UI)
todo: make grid selection list sticky?
todo: put sample wiki in docs or maybe in UI as a thing you can click on to insert it into current wiki if empty !!!
or both
Then remove from seeder entirely
todo: WIKI insert image should have extra linefeed before and after because it fails to show the image at all if it follows something like <br> even though it appears to be on the next line
- tl/dr: ensure blank before and after for any url
todo: History - MORE button not showing? Was looking at administrator history for AA import scott
- also, is it showing other types of objects besides Users and Customers? (not seeing wo)
todo: readonly on all forms make sure it's ok, because on customize form I see no save but can edit
- (logged in as bizadminlimited)
todo: when server is in ops only mode the client needs a way to prevent people from opening things that they shouldn't.
This may be a non-issue, test it first. I think it now correctly reports the issue and all ok
First of all, test and see what happens in NON dev mode at the client
for example if a admin logs in they can and should access serverstate page and some other stuff ops related, but all other routes should be locked out
I know the server will send a 404 or something but maybe that needs tweaking to show a proper message at the client or just not show those options or something?
(part of long polling maybe??)
todo: OPEN OBJECT HANDLER
Update it to check if a child type and if so then it calls get ancestor at server search route
Search controller route: ancestor(ayatype, ayaid) returns type and id
todo: found more presets in cases
can I do this date range preset:
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3343
or is it a feature of some kind on it's own
This one: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1441
todo: router should check rights on each route shouldn't it?
- or should the form check and nav backwards if they don't have the rights
- test: login as subcontractor and direct open widget object
TESTING PERF/USABILITY
todo: keyboard usage test:
https://www.sarasoueidan.com/blog/keyboard-friendlier-article-listings/
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3481
todo: Login form customizable for logo etc?
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3592
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1849
- possibly other cases?
- Still on the fence with this one, I mean why should we give up our branding, on the other hand if people MUST have it maybe a co-logo
Why exactly DO people HAVE to have it? So they can pretend they made it?
if they think their customers would be confused maybe all it needs is the company name predominently on it?
Seems weird to give up our branding and logo in the only place it's actually displayed beyond our marketing materials
Give this a serious thought because it seems like we might be being shitty to ourselves if we support this
todo: Customer UI pages ability to add analytics tracking codes:
CORS implications?
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3574
todo: ADM-USER awaiting customer, headoffice id, etc for those usertypes
need to show if that usertype for selection
todo: open-object-handler.js deal with some utility types:
//TODO: FORMCUSTOMIZATION
//TODO: LIST VIEW
//TODO: Items that are able to be opened from the adm-history form
//need to decide to support them and if not then need to modify the message below
//to be localized and simply say "Can't open this object type" or something along those lines
//TODO: also an alternative might be to have a CanOpenObject method in open-object-handler that is consulted by data-table control before it builds links
todo: NOW THAT FORM IS THERE MOSTLY, CLEAN UP CODE FOR RE-USE in many other forms
- Look for things to componentize
- Can I componentize the whole form itself so that I have all the basic requirements built in and can just customize certain things for each object type?
- Look for things that are not specific to the widget edit form but can be abstracted away for other forms
- Don't need to replicate common code so put it somewhere else
- Are any of the controls better as a component and self contained to save the size of the form code and complexity?
- What I mean is, for example, a text entry field could be standardized then re-used as a component if it's props and settings take up so much space etc
- formstate shit is also menu shit really so can they be combined somehow, like present two sets of menu options one read only and one fully read-write?
- some forms will have special needs but could handle them outside of the regular boilerplate shit?
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: Document in user manual the Widget form as an example with instruction on how to use the various controls etc
- "Anatomy of a AyaNova Form"
todo: INSTALLER
Might need to move up the installer so that Joyce can test and can just install it standalone and test out shit
Windows installer for first iteration
include the portable postgres
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
=========================================================================================================
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 3
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
This stage is to consolidate the basics and set the final shell form.
A lot of it might be rundundent
TODO: GRIDS I'm still on the fence with the grid sort and filter system
Filter is ok, it's complex and people don't expect it to be super easy, but sort is a bit of a palaver
Column visibility selection is also ok and not used enough to really support it on the outside so that could stay
Sorting is the big issue, seems ugly to sort by going into the component when it's such a common need out of it, but we could live with it if necessary
TTM rules this decision maybe but usability is a big one here too
it seems too difficult to make a quick sort change, can it be supported to just click on column headings?
Maybe need a hybrid grid that can be used to select columns and order and filter but sort order is on the outside
And can turn off column selection if it's a simple thing so you get all the rest built in but don't see the filter list nor filter icon if set to that mode
This way can use it all over and where appropriate
todo: Go through all cases, just glance over them and make sure nothing was missed that impacts the basic shell stuff before I get into the real world objects
todo: INVESTIGATE / REDO THE TOP LEVEL SHELL - TIME TO MARKET / Is my shell layout fucked?
- wouldn't it just suck to have all those lists exposed at once in inventory?
- Opening that page once they are all there would trigger huge traffic to the server, better to confine things to their own area as much as possible
- TTM: isn't it faster to just turn the menu into a tree like v7 or put options in each one's screen? (Like inventory page just shows a bunch of other icons to open details like widgets)
- TTM: I'm concerned that the modular UI is a bit too ambitious, yes it makes sense for re-usability but exposing it to users so they can redo their UI seems crazy ambitious at this point
- People just want to work and simpler is always better, less to maintain
- How about the easiest simplest layout possible even if it's a bit uglier but keep it all clean and focused instead of too much shit on each form?
- Really, for maintainability it makes sense to have a very simple clean layout and not try to put a bunch of complex controls all over the fucking place!!
- I need to make money from this, not win prizes for design!
- Easier to show or not things for authorization purposes when they are each in their own navigation path as much as possible
- users are used to a certain thing with v7 why re-invent the wheel, just clean it up and modernize where necessary
- There are so many other things I need to focus on, this is just adding complexity in an area that might be a nightmare to maintain and troubleshoot.
- DON"T get too fancy with this, my instinct is to make it more complex all the time, but actually ugly and simple and effective is better than pretty but fucky to use
- Also, mobile really doesn't go well with fancy but more with clean and simple.
- Sounds like my minds made up, this issue is more about changing the SHELL UI
- IDEAS:
- old fashioned switchboard kind of thing, big buttons for each area sit in a row, on mobile they are vertical full width?
- ugly but effective
- Alternative is a Tree control in menu instead, but that would likely be ugly in mobile(could investigate but it's not common probably for reason, look at material apps on phone see what they do)
- Don't worry about having to navigate too deep with too many clicks for the top level, yes some won't like it, but it's more important to focus usability and minimizing clicks in the actual path that day to day users take
- In other words make the most common tasks quick to do from the top level / HOME screen perhaps and *thats* where to focus on customization so users can surface what they want there as a LINK
- Users can modify what shows by default in the home screen but not the fancy active widgets I had envisioned but instead different task based buttons / links so they can get to where they need to go quickly
- e.g. click on inventory, select the Widgets switchboard button, the widgetlist opens full screen to the right side, one of the menu options is "Add to home screen" with a favorite button
- They click on add to home screen and next time they are on home screen a new button / link is there to that item, autoamtically pre-grouped by area of functionality or maybe they can just order it how they see fit?
- I really like the idea of the widgetlist being full screen to the right rather than in a component sharing that space as it's pretty necessary
to have a lot of columns display at times, yes it's a ui made up of a bunch of lists but that's really what people understand, it's appropriate to the application,
no business software can simply hide everything and it doesn't have to suck or be ugly
todo: test error conditions with dev mode off
todo: Clean up TODO list, have only actionable, not completed items.
- Make a to_test.txt doc so can move todo's to to test doc for testing
- anything in this doc that isn't related directly to individual todo's other than a small big picture stuff at top sb elsewhere
- Idea is to have a focused, clean actionable list here.
- Prioritize any basic stuff that will be replicated over and over again
- i.e. regular edit forms, not schedule or workorder form which will require their own separate work and are not replicated
- want to get going with all the background object types like clients and users etc before I try to make the schedule and workorder forms
- Identify any unique time consuming items and put them in their own block of todo's
- Self serve server stuff
- workorder form
- Accounting integration and other plugins
- import datadump etc
- There is a lot of crap at the bottom of this document in this todo!
todo: INVESTIGATE - DO I need to institute a back button? (in APP MODE?? installed to "desktop" on device will I be able to easily navigate without back and forward buttons)
todo: MRU
- is this covered by history adn should it just be a quick link to personal history instead?
- MRU in dashboard...where? https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3723
- GOOD case here with two great ideas (using "audit log" event log for mru or AS mru and doing it all locally (which I am, no MRU at backend))
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3442
### RETEST ALL DEVICES WHEN GET TO HERE #####
TO TEST:
- above changes block
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 4 - REPORTING / DASHBOARD / KPI
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Do reporting and dashboard here
Read over and maybe develop in parallel a bit here a bit there from client down to server as much of this code will overlap in theory
Reporting and dashboard are tied together in a sense because they both need similar data and likely will need similar controls etc
todo: DASHBOARD
- Joyce kpi / charts and graphs
- these cases:
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/2024
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1974
Won't have workorders, will need to test with widgets and users, maybe clients will be ported?
todo: REPORTS v8 MIGRATE / EXPORT (CUSTOMIZED NOT STOCK) FROM v7? Try to see if plugin can export any aspect of reports
code behind?
even if just exported as comments in js for the new format just to have the formula's etc
basic layout, maybe as HTML?
anything that would help, even just the name of it and it's existence and a TODO in the middle is better than nothing at all
Any info to assist report designer with V8.
Be nice to see field list with translation for equivalent new.
todo: REPORTING wiki Download, open as pdf, email?
- is this a reporting issue? I think it is, moving to reporting
todo: REPORTING wiki in datalist?
- will need for reports but can't show in a grid, maybe it's available for something but can't be seen or filtered?
- shows in grid as basically a bool like has wiki or not but doesn't show any actual wiki?
- this is only to feed report, no other purpose to it.
todo: Report editor for creating new report accessed from the report any **existing** reports preview form if have the rights.
- or maybe from the report selector dialog box if they have the rights, although would that fuck up navigation process?
- This seems better because, what if they can't preview a report for some reason, then they can never fix it or make a new one?
- NOT like v7 where accessed from the object edit form (this is to keep menu options down to a reasonable number)
- Every list sb reportable case https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3653
- Also search results and history? Can feed from UI level to report component?
- Reporting case with various things pertinent to look over BEFORE starting in on this:
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3451
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1849
Instantly print? https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/818
Guy took the time to request it, so have a look think and see if there is a way to do this
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1734
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/962
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@ ROADMAP STAGE 5 - FINALIZE ALL NON BIZ OBJECT SPECIFIC FUNCTIONALITY
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
todo: Much of this stage below needs TRIAGING, do that first.
Any real (corebizobject) shit goes to stage 7
todo: MAPPING
getting a *lot* of request about this
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1816
maybe stage 7 or I guess could fake it for now, it's going to be known what will be needed
https://news.ycombinator.com/item?id=23722133
https://blog.mapbox.com/openstreetmap-a-global-map-for-worldwide-insight-4e041cbf1ec1
todo: can I support keycodes for saving in AyaNova and other shit that are the same as in v7 or as much as possible, i.e. ctrl-s to save (or whatever was defined)
What v7 used to support:
f1 - help, case (Keys.Alt | Keys.X) //Close form, alt-w new workorder, alt-m new pm workorder, alt-q new quote, alt-c new client, alt-u new unit, alt-p new part, ctrl-alt-g grid criteria for development,
IMPORTANT / DO THIS: insert date and time (localized) as text anywhere with a key combo
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1514
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
todo: clickable urls
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1738
-----------------
TODO AFTER CLIENT block ABOVE:
TODO: ON UPDATE TO NEW version
have an url that opens automatically or a notification and link to one after a new version has been detected just
like visual studio does in order to show what is new in this version
maybe ideally it opens to a new document page "whats new in version x.xx"
this way no need to go beyond the local server or hit our site unnecessarily
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 6 - INSTALLER, LICENSING, ROCKFISH SUPPORT FOR RAVEN
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
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: Suggestion box: BETA MODE Feedback form?
There is a suggestion box case here somehwere
Sends errors, server log, suggestions etc, directly to rockfish?
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
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 7 - "REALITY"
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
All in on porting over all the real objects from v7
todo: First of all triage the features to port over in the sanest order so not stubbing too much stuff
Try to get scheduleable stuff early because schedule form will take some time
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
todo: Notifications
Many are on hold until there are real objects to code against, now is the time to code them as the objects are added
todo: can beta test at this point
post installer, enlist trial users get feedback, don't get too down when they shit all over it as they will undoubtedly :)
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
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
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 8 - PLUGINS
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Plan the order of criticality for plugins
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
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ ROADMAP STAGE 9 - RELEASE
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
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
@@@@@@@@@@@@@@@ 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
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
Reference in New Issue View Git Blame Copy Permalink