devdocs/specs/core-license-key-system.txt

@@ -24,7 +24,7 @@ LICENSE BOOTSTRAPPING
 		- Also this is the new fetch code
 	- RAVEN Is unlicensed it should check for a new key on a shorter frequency loop rather than once a day?
 		or, providing a button to trigger that should be enough really
-		or when server starts it starts the GENERATE loop and checks for a key right away, so they can just reboot teh server if they want an immediate license check?
+		or when server starts it starts the GENERATE loop and checks for a key right away, so they can just reboot the server if they want an immediate license check?
 	
 
 	- RAVEN DB is empty (of biz data) it's license locked and a User MUST DONE ONE OF THE FOLLOWING:

devdocs/specs/core-notification.txt

@@ -24,7 +24,7 @@ BACKEND TODO / SYSTEM FOR RAVEN
 
 IMPLEMENTATION PATH / PLAN - code as minimal a route as possible to get to working notifications end to end with minimal subset 
 	first is test notification which is done as an implementation of the GeneralNotification Event type and is delivered to the current use running the test
-		This will go through all potential problems or maybe trigger a troubleshoot route at teh server that checks all and reports back with any issues found
+		This will go through all potential problems or maybe trigger a troubleshoot route at the server that checks all and reports back with any issues found
 		Also needs to be localized (do the test route thing, that just makes the most sense.  The test route should accept the type of notification i.e. inapp or smtp, act accordingly if it's a customer user vs regular if there is any difference)
 		Should report to user exactly any issues found at any level preventing it from happening
 		Should submit as a job and await running in place like other ones so that its actually working end to end with the generator	

devdocs/specs/core-reporting.txt

@@ -119,7 +119,7 @@ todo: MEMORY / PERFORMANCE / CRASHING
 
 				
 todo: memory usage and timeout is directly related to the amount of space taken up physically on the page
-	it's NOT related to the helpers as just putting static text on the page causes teh same issue
+	it's NOT related to the helpers as just putting static text on the page causes the same issue
 	it's memory taken to render to pdf probably and a byte is a byte even if it's blank white page
 	=-=-=-=-=-
 

devdocs/specs/core-workorder.txt

@@ -7,7 +7,7 @@ If each part has it's own concurrency then can submit whole and bits that aren't
 
 
 CONCURRENCY decision / research - updating, in bits seperately, entirely at once? [## DECIDED, BITS MAKES MOST SENSE AND DIRTY TRACKING AT CLIENT ##]
-	Considering we are looking at a system where some users won't see or even get the data for some parts of teh workorder then it's important that they be able to just save their piece of it separately
+	Considering we are looking at a system where some users won't see or even get the data for some parts of the workorder then it's important that they be able to just save their piece of it separately
 	So this strongly leans towards seperately saved and not entirely at all.
 	concurrency issue reduction 
 	Things that might require an entire workorder graph be updated at once:
@@ -38,7 +38,7 @@ CONCURRENCY decision / research - updating, in bits seperately, entirely at once
 			Actually isn't this just handled at the server as a biz rule?  (no because if header saved first then it's locked potentially and sub items can't be save subsequently in a graph walking save)
 		New items are always dirty so a new labor record added would be dirty and saved individually
 	 	At the server upon item being saved there would always need to be a quick check of the entire workorder to see if it's LOCKED status or not
-		 	if locked then bumps back with error that wo is now locked (of course they could just change teh status in the header and resave I guess)
+		 	if locked then bumps back with error that wo is now locked (of course they could just change the status in the header and resave I guess)
 
 
 UI stuff
@@ -47,7 +47,7 @@ UI stuff
         so a single workorderitem workorder would have all fields exposed and if any grandchildren those are entered in a single form too until the user has more than one 
         
         in v7 it's three clicks to go to a grandchild items specific field from the top header, woitem click -> left nav button row selection of area click -> grid row column click
-        in v8 it would be one more click then if it was a multi record grandchild but if it was a single record all teh way down then all would be exposed and visible at hand could go directly to the field in question
+        in v8 it would be one more click then if it was a multi record grandchild but if it was a single record all the way down then all would be exposed and visible at hand could go directly to the field in question
             so in this concept every level exposes an edit form below a grid of one or more items, but grid doesn't show if there is one item so it's very clean.
             if there is no record at that collection then just a click to add button as unobtrusive but clearly marked as possible (if user has selected to hide that section then doesn't even show and some users don't see at all)
             if multiple at that level then a grid to select the active row to edit below it showing as much data as possible in each row to help user see at a glance while editing a sibling item