devdocs/todo.txt

@@ -9,42 +9,35 @@ Import / update
 	JSON AND CSV both supported
 	CSV column headers MUST be the same names as JSON property names
 		CSV is turned INTO JSON at the client then submitted to the server so the server only handles importing JSON, never sees CSV
+		Client reads in the csv and makes json objects looking for the matching expected names
+		Order of CSV does not matter as long as there is the minimum required NAME field to match and anything else that's required
 	Import and update are same code and handled by CONVENTION (salesforce uses this convention)
 		Matching is always done by unique name (or whatever the unique identifier is)
 		Any new objects that don't match by name in the file are added always without exception
 		Any matching objects that are in the file are UPDATED to match the file values
 		Specific fields can be NOT updated by simply not including them in the import file
 			This is the convention
-
-
-
-Import feature
-	currently imports in the format as exporting, 
-	It works but it will bomb if there are linked records with wrong id's as it creates an exact copy of the json so not sure what use this would be as is
-	A proper feature for this would likely need to work with a more limited subset of records and it needs to be targetted to a specific task only like in v7
-	in v7 you don't import head office with client, just client alone as it limits the fields and collections to be imported
-	I'm thinking rather than throwing a generic solution at this it needs to be targetted to work direclty with the types in question
-
-	Almost need to ditch JSON export entirely?
-		actually, json export is ok, it's the json import that is sketchy, perhaps if it stripped fields?  Or created a head office from the viz field if found and ignored ID's?
-		do we want data transfer this way ayanova to ayanova supporting everything?? That sounds more like some kind of other synch tool or something
-
-	CSV should be the roundtrip format for ayanvoa and
-	Import should be all about onboarding and nothing else.
-	Lots of people use the update feature to update part prices etc so that should be a part of it
-
-
-	test recent code change for "importable" attribute back and front then test the items to see if they work
-	hasn't been tested in a while, confirm what works and what doesn't, remove anything that doesn't work, look at an import path for inventory
-	most important to test in order are:
-	Customer, vendor, parts
-	All workorder and sub items should be removed from import, it doesn't make sense to import work orders here as far as I can tell, lock down this list
-		to only the essential, working items for now.
-	We may need a full blown inventory import feature of it's own, perhaps an item on the list that opens a different set of features in the form?
-
-	Importer maybe for inventory has match to field setting in source data as ID or name or whatever so match field in import "Part" to field in ayanova "Name"?
+			So, for CSV it goes by header field name to determine if it should be updated / imported or not
+			for JSON it could actually work record by record, so they could leave out the retail price property entirely for some records and include it for others to be updated (side effect for free as that's how the back end will treat it)
+		Back end import must handle each item one by one and decide if update or add and act accordingly working with the convention
+TODO:
+	All changes should be schema updates now so users don't have to erase their database at this point (too much hassle to explain it)
+	Remove chinchoo CSV export code, update front end and docs to hide it completely
+	Front end work to support json or csv files
+	help docs to explain it
+		help docs should have an example of at least two records of JSON and CSV to show the full field names and somehow indicate which ones are absolutely required
+		probably a single page for each object, i.e. admin-import-customer.md, admin-import-part.md etc
+	back end code to work with convention to import
+		back end must ignore any linked id's but can use viz fields to match perhaps?
+		(we could use a different format for the import json since it's not a direct one to one json to class anymore, but maybe still viz fields to match?)
+	Front features:
+		Should warn the user about updating versus importing etc, maybe just a warning when accepting OK do the import that specifies 
+		"the following operation may change existing data" are they sure and have read how it works with a MORE infor link to manual
+	Once it's working then can see about expanding to other objects
+	If add translation keys should try to do it as a schema update now
 		
 
+
 get back to docs completion
 
 Wednesday / thursday march 23/24th check this in chrome: https://search.google.com/search-console?resource_id=sc-domain%3Aayanova.com