This commit is contained in:
@@ -25,14 +25,6 @@ Prioritize anything that stands in the way of beta testing
|
||||
|
||||
TODO:
|
||||
|
||||
Update all dependencies
|
||||
Server section below for the AGE interval bug then can go back to regularly scheduled items
|
||||
datatable wolist fucked
|
||||
this is due to the AGE thing and the interval being more than a month, see if can change the age query to return total minutes or some such shit instead
|
||||
and avoid months which is the issue here
|
||||
also needs to see if it's affecting any intervals used anywhere else in ayanova like can you select months in a contract/pm/notification etc?
|
||||
Weeks is the highest safe time frame interval that can be used with this but I'm almost certain there are months in there somewhere
|
||||
|
||||
reporting issues
|
||||
test restore the big db here privately and confirm
|
||||
testing cases
|
||||
@@ -252,11 +244,39 @@ TODO: 1 BETA DOCS:
|
||||
|
||||
|
||||
|
||||
- 1 todo: on linux server test discovered lightbulb sample reports are coming up in listing first which is not what is expected change to z as first character and test on all platforms to confirm
|
||||
- 1 todo: timeout is not be working, try to test it, joyce having issues
|
||||
she's using it heavily and it's constantly locking up as in furiously processing away a stuck report seemingly without end
|
||||
There needs to be a overall sanity timeout for this shit and I need to test it with some reports that just endlessly spin on some wait(true) type bullshit
|
||||
|
||||
research:
|
||||
actually, it seems like maybe it's not the rendering process but the query itself that is slow because once the query is done the rendering is very fast
|
||||
the bagcheck happens before the query runs so the real problem may be the speed of the query and needing a way to timeout the query or cancel it if it takes too long
|
||||
Currently looking at workorderbiz getreportdata method to see why it's taking 20 seconds to process 100 workorders which seems crazy slow
|
||||
|
||||
Workorderbiz::GetReportData took ms: 26239
|
||||
|
||||
NEXT UP break out the fetch from the process timing wise and see which part is slowing it down
|
||||
Before any changes:
|
||||
Workorderbiz::GetReportData took ms: 22987
|
||||
Workorderbiz::GetReportData took ms: 19131
|
||||
Workorderbiz::GetReportData took ms: 28449
|
||||
Workorderbiz::GetReportData took ms: 25477
|
||||
Remove populate viz:
|
||||
Workorderbiz::GetReportData took ms: 4174
|
||||
Workorderbiz::GetReportData took ms: 3659
|
||||
Workorderbiz::GetReportData took ms: 3811
|
||||
Workorderbiz::GetReportData took ms: 3878
|
||||
DING DING DING!
|
||||
Only remove woitem populate:
|
||||
Workorderbiz::GetReportData took ms: 4845
|
||||
Workorderbiz::GetReportData took ms: 5026
|
||||
Workorderbiz::GetReportData took ms: 4955
|
||||
Workorderbiz::GetReportData took ms: 4926
|
||||
Remove all *except* woitem populate
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- 2/3 todo: there are no default reports for any objects except a selected few, thought joyce was making a report for every object that's reportable
|
||||
will need to make a slew of default plain reports like customer etc
|
||||
@@ -289,6 +309,7 @@ TODO: 1 BETA DOCS:
|
||||
- 1 translation cleanup, work order sb Orden de trabajo but is translated as Pedido?! (which is very generic and not work order, usually like a restaurant order or online shipping order sense for pedido)
|
||||
I did a couple but realized it needs to be done one by one roundtripped carefully as it's used in alternative tenses and forms throughout
|
||||
|
||||
-2 ops server information is missing some settings like report rendering max instances, go over the serverbootconfig settings and look for missing items to add
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user