This commit is contained in:
@@ -3,26 +3,9 @@
|
||||
|
||||
Import / export features
|
||||
|
||||
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
|
||||
https://www.papaparse.com/
|
||||
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
|
||||
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:
|
||||
OUTSTANDING:
|
||||
docs incomplete for import form section showing UI fields and menu options (awaiting trans keys)
|
||||
|
||||
replicate customerbiz import code to all the other supported objects
|
||||
test each object
|
||||
document each object
|
||||
|
||||
Reference in New Issue
Block a user