devdocs/todo.txt

@@ -1,6 +1,22 @@
 # now
 
 
+Import / export features
+
+Export - JSON only, no csv, remove the csv export, export anything exactly as it is now probably no change required
+Import / update
+	limited specific subset of objects from admin import page (rename that to "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
+	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, 
@@ -8,6 +24,7 @@ Import feature
 	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