devdocs/solutions.txt

@@ -126,7 +126,7 @@ https://en.wikipedia.org/wiki/Non-functional_requirement
 
 - REST best practices
     - Excellent reference guide here: https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md
-    - URLS: A good api url: https://api.ayanova.com/v1.0/client/22  
+    - URLS: A good api url: https://api.ayanova.com/v1.0/customer/22  
         - Keep length under 2000 characters for maximum client compatibility
         - concurrency (The ETag response-header field provides the current value of the entity tag for the requested variant. Used with If-Match, If-None-Match and If-Range to implement optimistic concurrency control.)
     - JSON property names SHOULD be camelCased.
@@ -135,11 +135,11 @@ https://en.wikipedia.org/wiki/Non-functional_requirement
     This object MUST contain name/value pairs with the names "code" and "message," and it MAY contain name/value pairs with the names "target," "details" and "innererror."
     eg: error:{code=1200,message="blah"}  error:{code=1200,message="blah",target="eg property name", details="details for programmer", innererror:}
     - Versioning: this is an area I need to treat carefully, there are tools to make it easier: 
-        - I will use URL Path segment versioning, i.e. api/v1.0/client/22
+        - I will use URL Path segment versioning, i.e. api/v1.0/customer/22
         - https://www.hanselman.com/blog/ASPNETCoreRESTfulWebAPIVersioningMadeEasy.aspx
         - https://github.com/Microsoft/aspnet-api-versioning/wiki 
         - https://github.com/Microsoft/aspnet-api-versioning/tree/master/samples/aspnetcore/SwaggerSample    
-    - Push notifications  (I.e. on a client record being created or a workorder updated or...?) 
+    - Push notifications  (I.e. on a customer record being created or a workorder updated or...?) 
         - If so there is a segment in the rest doc from microsoft that goes over it in detail
     - API THROTTLING / RATE LIMITING
         - https://github.com/stefanprodan/AspNetCoreRateLimit

devdocs/specs/core-roles.txt

@@ -10,6 +10,10 @@ ROLES set general accessibility to change or delete or read objects, however Bus
 **DELETE RIGHTS***
 If you can modify an object you can delete an object unless business rules say otherwise
 
+**SEE NAME / PICKLISTS ***
+    - Not sure if correct but for now assuming anyone can read the name of any object and that the UI will exclude them by biz rule if they aren't supposed to see something
+    - this does mean a subcontractor could use the api to fetch a list of customers outside of the client though...hmmm..
+    
 
 **LIMITED ROLES / BUSINESS RULES LIMITATIONS **
 (formerly self owned)
@@ -17,7 +21,7 @@ In some cases business rules may further restrict what a user can do.
 For example a SubContractorLimited has the change right to a workorder, but in fact the workorder itself has business rules that limit that drastically down to almost nothing but a single area entry in labor
 
 =-=-=-=-  HOW TO HANDLE EDIT OWN PLANNING =-=-=-=-=-
-- EditOwn is really not about editown it's about supporting a user who is not supposed to see any data other than the bare minimum in order to fill out workorders
+- EditOwn IS DEPRECATED FROM ORIGINAL PLAN is really not about editown it's about supporting a user who is not supposed to see any data other than the bare minimum in order to fill out workorders
 	- Make it a business rule(s) instead in the areas of workorders and anything specific
 	- Get rid of edit own rights code entirely
 

devdocs/todo.txt

@@ -20,7 +20,8 @@ UPDATE SPEC DOCS with new format and names etc or at least remove nonsense as ne
 UPDATE MANUAL API REGARDING LISTS
 
 
-
+CLIENT / TEST ROLE NAME CHANGE 
+	- "client" now "customer"
 
 
 CLIENT PROJECT CUSTOM FIELDS CHANGE
@@ -43,6 +44,12 @@ DO CLIENT STUFF NOW COME BACK TO THIS STUFF LATER
 TODO: the license being logged breaks the format of the log file because it has line breaks etc, so instead, maybe log out as a single line (remove breaks)
 	- Or maybe don't log it at all, what's the point?  People can just edit it, maybe the DBID is the only really useful thing so we can match it for support to the customer
 	- or just log the ID number or a more succint version
+	\
+
+TODO: Need route to gather all object role rights in a format useful to display in UI so that a biz manager can see at a glance the rights for different roles to objects	
+	- This way it's dynamic and picked up from the code itself which is always the source of truth so no need to put in the manual
+	- Would likely want to display multiple ways: for a specific object or role or selected user maybe too in the user info form ("effective roles")
+	- Move this over to client once the backend supports it
 
 *** BEFORE NEXT UPDATE TO DEVOPS SERVER:::::::
 TODO: 2019-06-07 10:47:57.8894|WARN|Microsoft.AspNetCore.Cors.Infrastructure.CorsService|The CORS protocol does not allow specifying a wildcard (any) origin and credentials at the same time. 
@@ -58,6 +65,7 @@ TODO: DO I NOT HAVE AN ERASE DB ROUTE?
 TODO: API RATE LIMITING / THROTTLING
 	- Return code 429 
 	- Going to need rate limiting to save people from themselves 
+	- Have this link from solutions.txt about this: https://github.com/stefanprodan/AspNetCoreRateLimit
 	- All the big api's have hourly limits on requests and also limits on total data throughput per hour 
 	- (minute as well which actually makes more sense since it means they would only be down for a minute if they exceed it) too
 	- Find out what others do