devdocs/coding-standards.txt

@@ -2,6 +2,28 @@
 
 
 
+Error messages / Numbers
+	- All server error codes start with E1000, all API error codes start with E2000
+	- Look for English text in all the messages so far and see if can be localized even crudely by google translate and do so
+	- Make sure error numbers have a consistent system and don't conflict, I think there are two sets of error numbers, there should only be one
+	- Make sure Every error has a number and that is documented in the manual
+	- Locale keys for error numbers??  i.e. E1000, "blah blah error 1000"
+
+Cleanup and sticking to the following code convention:
+	All names are PascalCaseOnly with the following two exceptions:
+		- function paramenter names are ALWAYS camelCased
+		- CONST values are  ALL_CAPS with underlines between for spaces
+
+
+
+
+
+
+
+
+OLDER STUFF
+=-=-=-=-=-=
+
 #DISTRIBUTION / DEPLOYMENT
 - Linux folders to use:
     - Program files in /opt

devdocs/specs/core-log-business.txt

@@ -1,29 +1,47 @@
 Business history log
 
 FROM CASE 79
-
 A central event log used to track changes to business objects and events of significance in AyaNova.
-
+??Has some sort of checksum or verification so we can tell it wasn't fucked with
-Auto prunes (can be set)
-
-Has some sort of checksum or verification so we can tell it wasn't fucked with
-
 Consumed by various widgets for record history purposes
-Each object defines it's own set of event id's of significance (int enum) in addition to some events common to all objects: 
+Default feature, no need to turn on or off keeps logs for 45 days, users who want more can 
+Items are only removed from log when source object is deleted (and replaced with a deleted entry and textual description of deleted item)
 
-1=created
-2=modified
-3=deleted
 
+EVENT_TYPES
+-----------
+A master enum of all event types in RAVEN.
+Co-used by this log feature, but also used by notification system
+Also used by localized text feature to fetch text about event for display in log and notification etc
+May be used for other things in future.
+Common event types that apply to any object and then specific event types that apply to particular types of objects but all in teh same master enum
+
+EventType
+ALL OBJECTS
+1 = created
+2 = retrieved (keep just in case, but perhaps not to be used unless high level of logging required?)
+3 = modified
+4 = deleted
+
+SPECIFIC OBJECT EXAMPLE
+Workorder:
+4=Closed
+5=Servicecompleted
+6=all parts set to used in Service
+7 = accepted from csr
+etc
 
 
 EVENT LOG DB SCHEMA
 ------------------------------------
 AYTYPE (object type int), 
 AYID (object id),
-AYEVENT (event of interest type int defined in object), 
+AYEVENT (event of interest type int defined in central master enum of all events), 
 TIMESTAMP (unix epoch), 
 USERID,
 TEXTRA (text field to identify stuff that can't be retrieved from source object, i.e. deleted record name) 
 
 
+TODO:
+1) Implement this log and routes to interact with it
+2) Implement an auto-prune job

devdocs/specs/core-ops-metrics.txt

@@ -15,6 +15,10 @@ https://www.influxdata.com/blog/how-to-use-grafana-with-influxdb-to-monitor-time
 5) Skim below and see if I have covered it all.
 
 
+Need to revise my metrics to bring in mvccore instead of mvc?:
+	- https://github.com/AppMetrics/AppMetrics/issues/261#issuecomment-404051808
+
+Might be time to order all this to the best effectiveness if it isn't already.
 
 
 

devdocs/todo.txt

@@ -8,32 +8,21 @@ Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOiIxNTI4MjEyNjI5IiwiZXhwIjoi
 CHOPPY DAY WORK
 +++++++++++++++
 
-
 https://severalnines.com/blog/performance-cheat-sheet-postgresql
 https://medium.com/@wesharehoodies/immensely-upgrade-your-development-environment-with-these-visual-studio-code-extensions-9cd790478530
-
+Changes needed to routes??
+	- http://www.talkingdotnet.com/actionresult-t-asp-net-core-2-1/
 
 	
 
 CODING WORK
 +++++++++++
 
-Need to revise my metrics to bring in mvccore instead of mvc?:
+Overall plan for now: anything standing in the way of making the initial client shell UI needs to be done first, everything else can wait
-	- https://github.com/AppMetrics/AppMetrics/issues/261#issuecomment-404051808
+	- Audit log
-
+	- Localized text
-Might be time to order all this to the best effectiveness if it isn't already.
+	- Search and search text indexing
-
+	- Auto visible id number assigning code
-Error messages / Numbers
-	- All server error codes start with E1000, all API error codes start with E2000
-	- Look for English text in all the messages so far and see if can be localized even crudely by google translate and do so
-	- Make sure error numbers have a consistent system and don't conflict, I think there are two sets of error numbers, there should only be one
-	- Make sure Every error has a number and that is documented in the manual
-	- Locale keys for error numbers??  i.e. E1000, "blah blah error 1000"
-
-Cleanup and sticking to the following code convention:
-	All names are PascalCaseOnly with the following two exceptions:
-		- function paramenter names are ALWAYS camelCased
-		- CONST values are  ALL_CAPS with underlines between for spaces
 		
 Created/Changed/Modifier/ Change / Audit log 
 	- Flesh out and implement fully
@@ -42,13 +31,7 @@ Created/Changed/Modifier/ Change / Audit log
 	- Tests
 	- Do I add more fields to the objects to cover same as v7 (currently only created is there in widget and others) or do I make use of the changelog table for that shit??
 
-Changes needed to routes??
-	- http://www.talkingdotnet.com/actionresult-t-asp-net-core-2-1/
 	
-Overall plan for now: anything standing in the way of making the initial client shell UI needs to be done first, everything else can wait
-	- Localized text
-	- Search and search text indexing
-	- 
 
 Ensure all modern best practice security is properly enabled on helloayanova.com so testing is valid
 	- https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Deployment_best_practices