This commit is contained in:
@@ -21,40 +21,23 @@ Import / update
|
||||
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)
|
||||
OUTSTANDING:
|
||||
front end translations and final text (as schema update)
|
||||
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
|
||||
|
||||
Front end work to support json or csv files
|
||||
if user opens CSV:
|
||||
read in csv if not column headers should barf
|
||||
convert csv to JSON, the proceed as if opened json:
|
||||
|
||||
Scan json fields in each item and ensure that they have minimum required field property names "Name" or whatever
|
||||
if any missing reject
|
||||
don't care if extra that won't be used, that's ok
|
||||
maybe rename viz from export to whatever the expected format is for importing a linked object by name (or keep viz just to be easier?)
|
||||
Once scan completed then issue dire warning about how it will not only import but also modify objects see below with help link
|
||||
once double approved then it goes to work and uploads to the server for import where the server does it's now back end magic
|
||||
|
||||
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
|
||||
TEST FILE OPEN ON iPad device as the file input accept type may not work with apple
|
||||
|
||||
TEST
|
||||
import csv, json, with and without tags
|
||||
update csv, json, with and without tags
|
||||
|
||||
Test build installers, will they overwrite properly adn schema update properly??
|
||||
once working and confirmed post update and upate the beta forum with NEW RELEASE
|
||||
does forum working need to be changed to not only issues but new updates there as well?
|
||||
"Known issues / updates"
|
||||
|
||||
get back to docs completion
|
||||
|
||||
|
||||
Reference in New Issue
Block a user