diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index e3f5e0de..aeab62de 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -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 diff --git a/ayanova/package.json b/ayanova/package.json index 9a8d1918..c7b362b8 100644 --- a/ayanova/package.json +++ b/ayanova/package.json @@ -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", diff --git a/ayanova/src/api/ayanova-version.js b/ayanova/src/api/ayanova-version.js index 8203fae2..a8fa8e20 100644 --- a/ayanova/src/api/ayanova-version.js +++ b/ayanova/src/api/ayanova-version.js @@ -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." };