From 6bbcd777f08b785b0121371b4fa37ef5024688a9 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Tue, 3 Aug 2021 22:20:02 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 39 +++++++++------------------------------ ayanova/src/main.js | 2 +- 2 files changed, 10 insertions(+), 31 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 754e2b1d..130d604e 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -35,7 +35,7 @@ Sept 1st Release! -## CURRENTLY WORKING ON: blizzard ** + ## MISC ITEMS THAT CAME UP @@ -510,28 +510,19 @@ todo:2 many biz objects are not using new PUT methodology ######################################################################################################################## -CURRENTLY DOING: notification outstanding issues: +CURRENTLY DOING: - Child->grandchild data lists for quotes and pm's like workorders - release - profit$ -PM TODO: - -test insufficient inventory - doesn't repeat - has correct quantities - fires when it should - todo MISC: + Child->grandchild data lists for quotes and pm's like workorders new workorder state set by default from global settings?? (and on generate from pm or quote) CLIENT generate new wo then go back goes to zero id new but then is stuck with error can't go back further due to broken rule shouldn't it skip this one like the others do?? @@ -549,24 +540,12 @@ todo MISC: sort by ID instead Notification code from workorder/quote/pm *item* grandchildren? Why is this a thing? shouldn't it be removed entirely, it's jsut wasted cpu cycles can a user even subscribe to any of these? Should they? - Scheduser schedule conflicts - should this not be processed on PM generation?? - i.e. skip the check to allow wo to generate?? - or report the error properly? - tough one, I'm thinking maybe skip rather than error out + - Add recurring job and notification about insufficient parts available for upcoming generations - totally doable and necessary - tricky part is tracking if it's been notified already or not, perhaps a time lock of some kind so it only does it if it falls on a certain threshold?? - or, perhaps if easiest just add a field to the pm saying it was notified (that is cleared when pm is edited) - Then close this case: - case 3583 ensure sufficient inventory (user want's it to look at all *upcoming* pm's and then alert parts are low or something, might be a notification type in there) - decided this is self fulfilling because server will generate wo from pm simulating when client does it and accepting the part requests - which will then trigger notification if set up and alert people that parts are required / taken from inventory - up to them the timing of how far in advance to do it to ensure sufficient time - Perhaps change this to a notification v.next case and still implement as planned which will partially solve this problem ITEMS section of workorder form needs to stand out somehow more, maybe a splash of color in the icon or something - + release + profit$ ============================ @@ -909,13 +888,13 @@ BUILD 117 - Workorder data table Added quote and pm parent columns to available columns this paired with bulk delete extension enables users to mass delete work orders from any PM accidents which result in a great number of undesired workorders being generated - Notification system - Fixed bug where object modified notification wasn't delivering due to missing line of code + Fixed bug where standard "object modified" notification wasn't delivering due to a missing line of code Added a "circuit breaker" to prevent excess notifications about system errors (case 3917) limits error type notifications created by server to once per 12 hour period to avoid scenario of thousands of notifications due to some unexpected repeating server error If an identical notification was already sent in last 12 hours waits until that has passed to send again doesn't affect normal object notifications becuase they may be duplicate on purpose (i.e. workorder status changes, object modifications etc) - Added three new notifications related to PM generation: + Added three new notifications related to PM generation (see PM help page for details): new notification when pm reaches stop generating date - PMStopGeneratingDateReached new notification when PM generation fails - PMGenerationFailed - New notification for insufficient inventory for PM generation - PMInsufficientInventory (case 3583 customer request) + New notification for insufficient inventory for PM generation - PMInsufficientInventory (case 3583 customer request, maybe sneek peak) (Notifies if upcoming PM will not have enough inventory to generate without making a part request) diff --git a/ayanova/src/main.js b/ayanova/src/main.js index b45201eb..3fd373bf 100644 --- a/ayanova/src/main.js +++ b/ayanova/src/main.js @@ -68,7 +68,7 @@ import chartBarHorizontalControl from "./components/chart-bar-horizontal-control //DEVELOPMENT MODE //THIS SHOULD BE FALSE IN RELEASE //************************************************************ -const DEV_MODE = true; +const DEV_MODE = false; //************************************************************ //************************************************************** //**************************************************************