This commit is contained in:
@@ -3,34 +3,28 @@
|
||||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
|
||||
|
||||
todo: pdf options UI and passthrough
|
||||
basically need to be able to select every option and send it through
|
||||
options:
|
||||
http://www.puppeteersharp.com/api/PuppeteerSharp.PdfOptions.html
|
||||
http://www.puppeteersharp.com/api/PuppeteerSharp.Page.html#PuppeteerSharp_Page_PdfAsync_System_String_PuppeteerSharp_PdfOptions_
|
||||
https://pptr.dev/#?product=Puppeteer&version=v5.3.0&show=api-pagepdfoptions
|
||||
page numbers control
|
||||
Test this, it might do what we need as it has a template for pdf footer and page number is part of it
|
||||
http://www.puppeteersharp.com/api/PuppeteerSharp.PdfOptions.html
|
||||
look at jsreport what do they include in their pdf post processing parameters and capabilities
|
||||
need to add pdfkit or whatever it's called at the front.
|
||||
DOCS reference pages
|
||||
https://stackoverflow.com/questions/49943479/puppeteer-header-and-footertemplate-doesnt-work#49996999
|
||||
https://pptr.dev/#?product=Puppeteer&version=v5.3.0&show=api-pagepdfoptions
|
||||
todo: REPORT BACKEND - more timeouts for report rendering, hard kill after 30 seconds tops but adjustable interval maybe?
|
||||
each process takes time in part, need to see which is taking which time the most and killable
|
||||
i.e. run a huge report and see which exact step takes which time for each
|
||||
we have the pre-render timing out maybe need more for each step where it's vulnerable to crashing / timing out
|
||||
|
||||
Devops droplet is overwhelmed by 10k records of widgets using the customfields example report
|
||||
symptom is super high cpu usage (100%) pegged and probably virtual memory usage as well
|
||||
timeout is kind of a hard core way to work around this issue, maybe instead it should be looking at excessive cpu and memory usage?
|
||||
The metrics don't catch it because it happens too quickly for the metrics lifecycle
|
||||
|
||||
I want it to be able to handle it gracefully without crashing
|
||||
Looks like jsreports has this issue too and they hard kill the process I think if necessary, but they actually re-use the same instance for reporting I think.
|
||||
If it's not an issue then no need to resolve at the moment
|
||||
|
||||
|
||||
todo: bizrule for report scale value at server
|
||||
and maybe other shit as well
|
||||
|
||||
todo: report delete throws server exception about db context re-use or something to that effect
|
||||
todo: REPORT BACKEND - report delete throws server exception about db context re-use or something to that effect
|
||||
No exact steps top repro, but happens for Joyce with win64 release build if go in and edit same template a few times from widget list then attempt to delete it
|
||||
try to repro on debug build figure it out, could be a big issue if it's not specifically a report issue but wider biz object issue
|
||||
|
||||
todo: trial license should print evaulation watermark over the report pages
|
||||
|
||||
todo: document (or tell Joyce) about the troubleshooting section items here:
|
||||
https://jsreport.net/learn/chrome-pdf
|
||||
which may or may not apply in our case
|
||||
|
||||
|
||||
|
||||
|
||||
//before getting into timeouts and shit make sure it's running as well as can be in docker
|
||||
@@ -48,20 +42,11 @@ todo: reporting load test
|
||||
test locally with 20k widgets, make it crash then determine what limits to set on it and properly return error when it's exceeded
|
||||
right now it just says something about puppeteer and "crash"
|
||||
|
||||
todo: trial license should print evaulation watermark over the report pages
|
||||
todo: bizrule for report scale value at server
|
||||
and maybe other shit as well
|
||||
|
||||
todo: more timeouts for report rendering, hard kill after 30 seconds tops but adjustable interval maybe?
|
||||
each process takes time in part, need to see which is taking which time the most and killable
|
||||
i.e. run a huge report and see which exact step takes which time for each
|
||||
we have the pre-render timing out maybe need more for each step where it's vulnerable to crashing / timing out
|
||||
|
||||
Devops droplet is overwhelmed by 10k records of widgets using the customfields example report
|
||||
symptom is super high cpu usage (100%) pegged and probably virtual memory usage as well
|
||||
timeout is kind of a hard core way to work around this issue, maybe instead it should be looking at excessive cpu and memory usage?
|
||||
The metrics don't catch it because it happens too quickly for the metrics lifecycle
|
||||
|
||||
I want it to be able to handle it gracefully without crashing
|
||||
Looks like jsreports has this issue too and they hard kill the process I think if necessary, but they actually re-use the same instance for reporting I think.
|
||||
If it's not an issue then no need to resolve at the moment
|
||||
|
||||
|
||||
todo: Need a setting that warns people about printing too much data, i.e. "That's a lot of data, are you sure you want to render that, it will be slow" or something to that effect
|
||||
@@ -74,10 +59,6 @@ todo: look at metrics snapshot lifecycle, perhaps it should be shorter as it's m
|
||||
todo: Take a serious look at .net5 migration, it will almost certainly be better to do it now than down the road after a release
|
||||
it also has many performance enhancements and nifty features like code analysis and warnings which might save me a lot of hassle
|
||||
|
||||
todo: look at what's coming on the radar before release in the big libs I'm using at front end as well, i.e. new vue or vuetify major release etc
|
||||
I would really like to release without a huge new migration looming over my head post release with potential breaking changes
|
||||
|
||||
|
||||
|
||||
|
||||
todo: triage this stuff:
|
||||
@@ -121,6 +102,8 @@ todo: LOGOUT UI button is still fucked on mobile
|
||||
needs a re-think, positioning it at the bottom is not working
|
||||
|
||||
TODO: ON UPDATE TO NEW version
|
||||
NOTE: This might all be due to package.json needing to have it's version updated
|
||||
it might be pulling that into the serviceworker for pwa or consulting it
|
||||
Right now it doesn't always refresh, have to manually do so, it should reload and ditch the cache on update, not sure why it isn't to be honest
|
||||
Try a test of it here locally and with release build, check network traffic, is it in fact actually updating and it's just the login page that isn't or...?
|
||||
|
||||
@@ -134,6 +117,8 @@ todo: wiki drag and drop image should automatically attach the image and do the
|
||||
todo: notification subscription form tags control looks like ordinary tags control might confuse people that they are tagging that subscription
|
||||
Maybe change the text to "Automatic filter tags" or "Only if tagged with"
|
||||
|
||||
todo: "lighthouse" score? PWA test tool for certification?
|
||||
|
||||
todo: export from grid to xls, csv etc.
|
||||
I'm thinking perhaps also a secondary ability to make report templates that are actually intended for export to xls or whatever as an additional feature
|
||||
but the easiest thing for people would be a straight export of grid data from grid, perhaps using the reportdata system since it pulls in all the bits needed for full data rather than just id links
|
||||
@@ -168,7 +153,36 @@ aspnetcore 5.x update
|
||||
|
||||
|
||||
|
||||
todo: (On hold pending testing) pdf options UI and passthrough
|
||||
OUTSTANDING
|
||||
Docs
|
||||
DOCS reference pages
|
||||
https://stackoverflow.com/questions/49943479/puppeteer-header-and-footertemplate-doesnt-work#49996999
|
||||
https://pptr.dev/#?product=Puppeteer&version=v5.3.0&show=api-pagepdfoptions
|
||||
todo: document about the troubleshooting section items here if applicable:
|
||||
https://jsreport.net/learn/chrome-pdf
|
||||
which may or may not apply in our case
|
||||
Testing
|
||||
|
||||
DONE
|
||||
basically need to be able to select every option and send it through
|
||||
options:
|
||||
http://www.puppeteersharp.com/api/PuppeteerSharp.PdfOptions.html
|
||||
http://www.puppeteersharp.com/api/PuppeteerSharp.Page.html#PuppeteerSharp_Page_PdfAsync_System_String_PuppeteerSharp_PdfOptions_
|
||||
https://pptr.dev/#?product=Puppeteer&version=v5.3.0&show=api-pagepdfoptions
|
||||
page numbers control
|
||||
Test this, it might do what we need as it has a template for pdf footer and page number is part of it
|
||||
http://www.puppeteersharp.com/api/PuppeteerSharp.PdfOptions.html
|
||||
look at jsreport what do they include in their pdf post processing parameters and capabilities
|
||||
need to add pdfkit or whatever it's called at the front.
|
||||
|
||||
todo: I have console logging capture code now in backend, but it's doing nothing really, just logs if exception thrown
|
||||
it might be handy if it returned the log value and any other diagnostic info with render return data when user is in designer
|
||||
i.e. have a further property Diagnostic bool and if set then returns diagnostic data
|
||||
and return property with pdf name would be in an object with additional properties for diagnosis etc
|
||||
But only if it proves helpful or necessary
|
||||
mainly this would allow a console log or error or trace to flow back to the user from the script being run at the server
|
||||
|
||||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
@@@@@@@@@@@@@ ROADMAP STAGE 5 - FINALIZE ALL NON BIZ OBJECT SPECIFIC FUNCTIONALITY
|
||||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
@@ -176,6 +190,19 @@ aspnetcore 5.x update
|
||||
todo: Much of this stage below needs TRIAGING, do that first.
|
||||
Any real (corebizobject) shit goes to stage 7
|
||||
|
||||
todo: FRONT END ROADMAP RELEASES (Sept 23 2020 was put on hold as it appears vuetify is way behind so looking like post release but check again here)
|
||||
look at what's coming on the radar before release in the big libs I'm using at front end as well, i.e. new vue or vuetify major release etc
|
||||
I would really like to release without a huge new migration looming over my head post release with potential breaking changes
|
||||
Vue 3.x is about ready now or very shortly: https://v3.vuejs.org/guide/migration/introduction.html#overview
|
||||
"The Composition API is purely additive and does not affect / deprecate any existing 2.x APIs. I"
|
||||
looks like I can switch to vue 3 without code changes, at least when it comes to composition api
|
||||
Vuetify 3.x is lagging way behind vue 3.x and doesn't appear to be even close so
|
||||
Put front end newification on hold until it all shakes out, looks like post release`
|
||||
|
||||
|
||||
todo: it would be *extremely* useful if we could run automated tests against the release ui with devops server
|
||||
|
||||
|
||||
todo: See if this has a use: as an aside there is a relative time formatter available which might be handy
|
||||
does locale aware things like "5 days ago" or "8 years from now" etc
|
||||
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "ayanova",
|
||||
"version": "8.0.0-alpha.16",
|
||||
"version": "8.0.0-alpha.20",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"serve": "vue-cli-service serve",
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
export default {
|
||||
version: "8.0.0-alpha.19",
|
||||
version: "8.0.0-alpha.20",
|
||||
copyright: "© 1999-2020, Ground Zero Tech-Works Inc."
|
||||
};
|
||||
|
||||
Reference in New Issue
Block a user