{"login": "manager","password": "l3tm3in"}




todo: MAYBE a datetime kind of parameter is interpreted as LOCAL by the server on a route
	so what the fuck
	sent from client http://localhost:7575/api/v8.0/server-metric?maxRecords=400&tsStart=2020-05-27T13:07:39.068Z&tsEnd=2020-05-27T19:07:40.068Z
	At server route: tsStart: {2020-05-27 6:07:39 AM}  tsEnd: {2020-05-27 12:07:40 PM} Kind=local for both
	so actually that's all good so far, how about the query itself?

	2020-05-27 12:13:38.6439|DEBUG|Microsoft.EntityFrameworkCore.Database.Command|Executing DbCommand [Parameters=[@__tsStart_0='2020-05-27T06:13:32' (DbType = DateTime), @__tsEnd_1='2020-05-27T12:13:33' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
FROM ametricmm AS a
WHERE (a.t >= @__tsStart_0) AND (a.t <= @__tsEnd_1)
ORDER BY a.t DESC
2020-05-27 12:13:38.8848|INFO|Microsoft.EntityFrameworkCore.Database.Command|Executed DbCommand (241ms) [Parameters=[@__tsStart_0='2020-05-27T06:13:32' (DbType = DateTime), @__tsEnd_1='2020-05-27T12:13:33' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
FROM ametricmm AS a
WHERE (a.t >= @__tsStart_0) AND (a.t <= @__tsEnd_1)
ORDER BY a.t DESC

	Well, shit.  The query is sending local time to the db server, so any query that sends to teh server needs teh values converted to utc first
	This is malarky pure and simple!
	:)

If change parameters to DateTimeOffset from DateTime and rerun exact steps as above:
2020-05-27 12:21:49.8196|INFO|Microsoft.EntityFrameworkCore.Database.Command|Executed DbCommand (21ms) [Parameters=[@__tsStart_0='2020-05-27T13:21:48.4840000+00:00', @__tsEnd_1='2020-05-27T19:21:49.4840000+00:00'], CommandType='Text', CommandTimeout='30']
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
FROM ametricmm AS a
WHERE (CAST(a.t AS timestamp with time zone) >= @__tsStart_0) AND (CAST(a.t AS timestamp with time zone) <= @__tsEnd_1)
ORDER BY a.t

* Now it properly is sending the value to the db in UTC as it stays IN utc from input to query
One thing though is it's casting the query to a timestamp with timezone which is weird but maybe because the column is defined as timestamp witout timezone

going to try 
	changing the model to datetimeoffset
	change database schema for mmetric to with timezone 
		no, actually for me it's better without because it will never try to interpret or change it, it will just return and accept it as is and
		that's what I want if I'm only dealing in UTC
	rerun again and see if it's casting still



todo: leave running check it does overnight backup properly

todo: add backup turn off setting
	environment variable
todo: add backup master time out setting
	environment variable

TODO: BIG UPDATE ALL GUTS


todo: notification?

todo: OPS notification created for failed jobs
	also maybe direct immediate email bypassing generator?
	Add backup fail to this will stub out for now

todo: (BREAK THIS OUT INTO LATER/NOW/CASES) there are several outstanding AUTHENTICATION related cases in rockfish for RAVEN
	e.g. https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1924
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1835
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1998 <---this is an important case for consideration
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3367 <--time limited accounts for support or temporary access?
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/2059 <--- time restricted accounts so user can only login during business hours (still to be considered)
	2fa stuff, some logging and lockout stuff
	Go through the auth related cases and notes in client side and implement or close
	todo: 2fa? (if not in first release, is there something needed to support it in future dbwise?)
	todo: Auth Backdoor reset password feature
		how to code it here, pretty easy to do:
		https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3250
todo: Look into 2fa
	https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3395
todo: look into how to use an SSL certificate with the RAVEN server directly when not behind nginx
	https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1
	- this should be supported by default out of the box working with Let's encrypt ideally
	- is it now considered ok to host .net core web api directly internet facing?
todo: onboarding and default manager account password
	- Need to come up with a safety plan for this so people don't leave it at default
	- Maybe the very first thing required of a user is to change the password before any tasks can be performed
	- Server stays in safety lock until they set a password?
	- Or maybe a random password is generated on seeding and somehow provided to user through console or something?
	- Maybe an empty db if no other users can be set password only so no one has made a hidden backdoor user account before ops changes it?
	- maybe tied to license if licensed so they bring some info they have from rockfish / their license purchase or something?
	- don't want it to be onerous too much and have some very inexperienced users so...
	- see what other programs do, like our forum software
todo: API docs, make separate page for datalists and remove from api-response-format.md doc but put a reference link to it there.

DEPLOY AND TEST 

todo: Test backup on Linux
	- going to need to run in vm I think maybe