516 lines
33 KiB
Plaintext
516 lines
33 KiB
Plaintext
@@@@@@@@@@@ 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
|
|
=-=-=-=-
|
|
|
|
todo: Translation list should have default sort by key descending when open it
|
|
|
|
todo: VERIFY FIXED JobExclusiveWarning missing translation at server
|
|
todo: VERIFY FIXED Job queue form has no column headers for jobs, should it?
|
|
|
|
|
|
todo: set network speed in dev console of firefox to regular 2g then go through all forms and confirm all still works as this will expose any await issues
|
|
todo: consider moving canDuplicate etc from a "computed" property into methods (just drag and drop)
|
|
in fact, look for all computed and consider them carefully because computed seems to be bullshit
|
|
todo: I don't really need About on every edit form, keep it for the main top level and remove it from all the edit forms
|
|
|
|
todo: concurrency violation tests, so far I don't think I've *ever* tested that from the client itself
|
|
|
|
todo: Check ops UI rights as limited user
|
|
todo: Check administration ui rights as limited user
|
|
|
|
todo: Backup, probably need to add option "Do not backup automatically"
|
|
or something to that effect for scenarios where the built in backup won't be used / won't work
|
|
|
|
|
|
todo: if dbid in url query parameter of contact form on server it should include that in the message
|
|
also something needs to be fixed there, it's been in notes forever
|
|
|
|
|
|
todo: error http://localhost:8080/adm-global-select-templates pick Customer get error at server:
|
|
Check other ones as well
|
|
2020-07-01 15:18:23.7324|ERROR|SERVER|Error=>System.NotImplementedException: PICKLIST NOT IMPLEMENTED
|
|
at AyaNova.PickList.PickListFactory.GetAyaPickList(AyaType ayaType) in C:\data\code\raven\server\AyaNova\PickList\PickListFactory.cs:line 26
|
|
at AyaNova.Biz.PickListBiz.GetAsync(AyaType ayaType, Boolean logTheGetEvent) in C:\data\code\raven\server\AyaNova\biz\PickListBiz.cs:line 58
|
|
at AyaNova.Api.Controllers.PickListController.GetPickListTemplate(AyaType ayaType) in C:\data\code\raven\server\AyaNova\Controllers\PickListController.cs:line 115
|
|
at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
|
|
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Logged|12_1(ControllerActionInvoker invoker)
|
|
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
|
|
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
|
|
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
|
|
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
|
|
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextExceptionFilterAsync>g__Awaited|25_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
|
|
|
|
|
|
todo: rename v8 export plugin to v8 Migrate
|
|
it's more accurate and easier to grasp for people (plus it rhymes)
|
|
todo: Migrate to v8 plugin needs to work with a trial database as well as a licensed database
|
|
It should check if a trial or not and give heavy warning if not
|
|
kind of cool if it checked for a recent backup before doing anything damaging
|
|
or triggered a checkpoint backup
|
|
|
|
|
|
todo: ability to mass tag items from list CLIENT UI
|
|
- See bulk jobs added to Attachment list
|
|
- Very likely this will be more appropriate as a per form menu option as it will require specific needs per type, or maybe not, just spitballing
|
|
- some kind of generic or copyable light interface for any mass / bulk job?
|
|
this will get re-used for other stuff undoubtedly down the road
|
|
- also a good way to do an initial implementation of a mass ops UI code
|
|
ability to mass rename a tag to something else in all objects
|
|
this is bizadmin level page dedicated to this kind of operation, list of objects and mass changes to be made
|
|
maybe this is a mass changes feature in general??
|
|
Or maybe just targetted to tags and can copy and re-use for something else if needed later
|
|
|
|
todo: notification
|
|
it's time, this is a big deal and it's tied to infrastructure shit so qualifies as an early thing to be done
|
|
add CLIENT long polling notification route check
|
|
add dummy route for above then flesh out
|
|
- Currently there is no UI area for notification display, maybe the settings one there would become that and
|
|
there are other ways to do settings already devised see specs / cases
|
|
- Notifications for OPS jobs? (Notify me when done kind of thing?)
|
|
todo: OPS notification created for failed jobs
|
|
also maybe direct immediate email bypassing generator?
|
|
Add backup fail to this will stub out for now
|
|
This is a bit outdated, lots of decisions already made and worked out in cases / spec docs
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3507
|
|
- Need way to acknowledge receipt of long poll info from client to server so that it can be removed or something?
|
|
- maybe successfull sending clears it regardless of client?
|
|
|
|
|
|
todo: dark mode
|
|
move out of user settings into bottom of nav panel maybe like the vuetify website shows
|
|
dark mode primary too bright?
|
|
|
|
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.
|
|
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: THIS! At this point, upload to dev server and thoroughly test with devices, it seems a bit slow at times
|
|
- Might need to hide attachments until user clicks on something to reveal as it seems odd to fetch every open
|
|
todo: careful and thorough PERF tests remotely and local
|
|
- https://www.digitalocean.com/community/tutorials/how-to-use-chrome-dev-tools-to-find-performance-bottlenecks?utm_source=DigitalOcean_Newsletter
|
|
- https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference#rendering
|
|
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
|
|
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: 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: notification system?
|
|
todo: bottom status panel thing?
|
|
|
|
|
|
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
|
|
- 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
|
|
|
|
|
|
|
|
todo: INVESTIGATE - Dark mode / theming (dark with a half moon icon)
|
|
- If it can be done with a half hour of work and doesn't affect anything support wise or maintainance wise then yes
|
|
- Also see how to allow theming maybe or colour choices? Nah, dark mode is the most useful; I should decide the colours and stick with them it's part of our image
|
|
|
|
|
|
|
|
### 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
|
|
- 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
|
|
|
|
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: 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
|
|
Do I need another payment processor?
|
|
Yes, fuck yes absolutely
|
|
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
|