Import feature is ready - need testers :)

The import logic for special fields should be with the fields, not with the import itself, so that it will become more flexible for future extensions/new fields.

Even parameters can be set for import, like -> process reverse geocoding for geo field import etc etc

Multilevelselect import by assigning the csv fields to the different levels (based on the max levels field parameter)

1) add additional column "imported" in #__js_res_import_rows which will be set after final import to make sure it was really imported and not stopped at step 2

This is additional query for every insert. if there are a lod or records might low down process. And new import does not use old rows anymore.

1) add additional column "imported" in #__js_res_import_rows which will be set after final import to make sure it was really imported and not stopped at step 2

2) Option to cancel at step 2 (maybe user is confused or not sure) which will result in deletion of the import records from step 1

It has automatic clearing. Every time anyone runs import it first clean import table and delete all rows from there more than 1 day old.

1) add additional column "imported" in #__js_res_import_rows which will be set after final import to make sure it was really imported and not stopped at step 2

2) Option to cancel at step 2 (maybe user is confused or not sure) which will result in deletion of the import records from step 1

3) Do we need CTIME in associate fields? The import should set it

For example I import my blog and time I made posts is very important. I think it should be there.

1) add additional column "imported" in #__js_res_import_rows which will be set after final import to make sure it was really imported and not stopped at step 2

2) Option to cancel at step 2 (maybe user is confused or not sure) which will result in deletion of the import records from step 1

3) Do we need CTIME in associate fields? The import should set it

4) textarea field type should be also available, since text is there already

yes I'll add it next update.

1) add additional column "imported" in #__js_res_import_rows which will be set after final import to make sure it was really imported and not stopped at step 2

2) Option to cancel at step 2 (maybe user is confused or not sure) which will result in deletion of the import records from step 1

3) Do we need CTIME in associate fields? The import should set it

4) textarea field type should be also available, since text is there already

The import logic for special fields should be with the fields, not with the import itself, so that it will become more flexible for future extensions/new fields.

Absolutely.

This is additional query for every insert. if there are a lod or records might low down process. And new import does not use old rows anymore.

Good, then still there is a need for a log file to see success .. if import crash, power out or field info (special characters, etc) will lead to crash, it can be exactly determined .. also other analytical purposes> This is additional query for every insert. if there are a lod or records might low down process. And new import does not use old rows anymore.

For example I import my blog and time I made posts is very important. I think it should be there.

ok .. agree ... :D .. btw, how about the date field import, if you have already the creation time there ...

What is the form_record_id for?

What is the form_record_id for?

What is it? Where it is from?

What is the form_record_id for?

how about the date field import

yes I'll add date field import too.

What is it? Where it is from?

Sorry .. my mistake .. i used an export from another source with unique id and they used this label... just mixed up to export files with same name while testing.

Sackgesicht

3) Do we need CTIME in associate fields? The import should set it

For example I import my blog and time I made posts is very important. I think it should be there.

Please, do not forget about my beloved "INITIAL create date" ;-)

choose an import mode on step 2. Either full import or update mode.

Full import = will update existing records and create new records

Update mode = only updates existing records and skip creation of new records

Log creation to see what actually happens.

Real world example would be synchronization with external data base, but Cobalt only uses a subset of info. I even have a scenario for it. I store user profiles in a TYPE, which needs to be updated from another system. They introduced new fields and encoded them there. I want to import them, but not create new users from there system.

BTW, is there a smart conversion of date formats? I mean, Cobalt stores a certain format and the import file may have many different formats or incomplete data. i.e. date, date and time.

Fixed

BTW, is there a smart conversion of date formats? I mean, Cobalt stores a certain format and the import file may have many different formats or incomplete data. i.e. date, date and time.

Supersonic-Admin mode: Create NEW content type and fields from file automatically ;-)

:D

BTW, is there a smart conversion of date formats? I mean, Cobalt stores a certain format and the import file may have many different formats or incomplete data. i.e. date, date and time.

Supersonic-Admin mode: Create NEW content type and fields from file automatically ;-)

Log creation to see what actually happens.

That would be nice. I have to start to collect feature requests for Import.

Import mode is also very good parameter.

After i finish core import process I'll start add features.

By the way was any one successful to import records?

By the way was any one successful to import records?

Yes, but just really simple tests, nothing fancy or complex. But I hope to do a test export of my ME Resources 3 types event-list, maybe classifieds next week.

Скрытый текст

I would like to help you test import feature

Tried to import files like described in step 1, but realized, that uploads field is not ready yet.

In the latest build i received 2 errors in step 2 that made it impossible to import since the title can not be selected anymore. i will make a fresh clean install to make sure it is not related to other things.

@chrissostomos, the import is already included in the new build. Create a new menu item and select import there.

BTW, is there a smart conversion of date formats? I mean, Cobalt stores a certain format and the import file may have many different formats or incomplete data. i.e. date, date and time.

I had a test file with this date format 20/01/2009

0 DateTime::__construct() [datetime.--construct]: Failed to parse time string (20/01/2009) at position 0 (2): Unexpected character

Please, do not forget about my beloved "INITIAL create date"

A) for new records it could be assigned like CDATE. If not assigned specifically it could be set = CDATE

B) update records should leave INITIAL date untouched. Only change it if the user assigned a specific CSV column.

BTW, what about other core date fields? i.e. blog posts or directory entries might have an existing "last modified" date. This should be imported as well. In short: Every Cobalt core date field should be offered on import and assignment.

In short: Every Cobalt core date field should be offered on import and assignment.

True. I will add some more fields later. When i finish adopting fields for import.

In short: Every Cobalt core date field should be offered on import and assignment.

A) for new records it could be assigned like CDATE. If not assigned specifically it could be set = CDATE

B) update records should leave INITIAL date untouched. Only change it if the user assigned a specific CSV column.

Not absolutely sure how you see шею Should inintime be the date of importing or set сешьу as inittime?

Regarding the import of a parent field, see my comments earlier.

Since parent does not store anything in Cobalt, it is not needed to be treated for input.

Importing into a parent field and selecting children at step 2 of the import does not make sense for me. A parent field should not be in the list of "Associate fields".

Import into a child field is wrong for me as well. If i select a parent in step 2, it would apply to all import records. Does not make sense to me.

Please check my earlier posting about child import (this would apply to an import of a parent/child setting from external sources):

But think of following scenario, which would help import parent/child field:

CSV 1 contains a column which would be considered the parent field (most probably a unique number from an external database like ID) for TYPE 1.

CSV 2 contains a column child for TYPE 2, which holds the value from TYPE 1 parent field.

Mandatory requirement is to import first CSV1 with parent field.

The parent field will be created as a text field first in cobalt (just to hold the info first).

When importing CSV2 with child, you query for the parent field field_value in #__js_res_record_values from TYPE1, get the record_id and uses this as the field_value of child field in TYPE2.

After the import the temporary text (parent) field in TYPE 1 can be deleted or you keep it as an "invisible" reference field for future imports of the same type.

Importing into a child field should present a field select where we can match the existing content to the content to be imported. Show all possible fields like you do it in the "exclude fields dialog".

Never mind the extra queries that come with this approach.

To optimize the queries in cases where the import content already holds the ID of the js_res_record table, offer additional the ID field in the select box.

If my explanation is too complicated, i can try to rephrase or provide examples.

Import of files should allow files with same name within 1 import process.

Example:

We using dates for file names, like 2013.pdf or 2013-06-13.pdf

One option could be that filenames can have a new format like 0000-2013.pdf, 0001-2013.pdf but then the import script will process the filename and store the realname based on a substr() or a certain rule which has to be defined.

Thinking further would lead even to an additional import mode "File based".

The filename contains several information which could be assigned to fields ...

If we upload a zip file which only includes the files without an attached csv, then 1 (first) filename will be parsed and divided in field infos and extension.

Example 2013#2013-06-12#sample.pdf --> field info is "2013#2013-06-12#sample" and extension is "pdf"

This will result in display of 3 associate fields under step 3. They will just be named Field 1, Field 2 and field3 ... one of the field choices would be "Real name Field".

In our case we could assign

Field 1 to a text field (content is 2013)

Field 2 to a date field (content 2013-06-12)

Field 3 to "Real name Field" (content sample.pdf)

or field 1 to "Real name Field" then it would store 2013.pdf

mport into a child field is wrong for me as well. If i select a parent in step 2, it would apply to all import records. Does not make sense to me.

There is no possibility to select child settings so that every imported article binded to different parent. Current scheme is create for scenarios like this. Let's say you are end user and you created 2 companies. Now you upload company products and you want to bind this products to certain company. You select company and all imported products wil be automatically binded to company and listed under its profile.

mport into a child field is wrong for me as well. If i select a parent in step 2, it would apply to all import records. Does not make sense to me.

Import of files should allow files with same name within 1 import process.

Unfortunately I do not know how to deal with that. If there are 2 files 2013.pdf in different subfolders and the same name listed in different articles in CSV that would be almost impossible to detect which file for what article.

So i think different file names is the requirement for import.

mport into a child field is wrong for me as well. If i select a parent in step 2, it would apply to all import records. Does not make sense to me.

Import of files should allow files with same name within 1 import process.

import script will process the filename and store the realname based on a substr() or a certain rule which has to be defined.

This is also hard to do. Where can you define this? Only in the code but that is hack. To allow user to enter PHP code to process data is incredibly dangerous. Right now I do not see how it could be done.

mport into a child field is wrong for me as well. If i select a parent in step 2, it would apply to all import records. Does not make sense to me.

Import of files should allow files with same name within 1 import process.

import script will process the filename and store the realname based on a substr() or a certain rule which has to be defined.

The filename contains several information which could be assigned to fields ...

This scheme sounds logical but to complicated for simple import and rathe solves problems of particular user. I think in most cases names of files are different. I know that you need this kind of import you describe but I cannot even imagine it.

Although as a solution, ir is possible to analyze CSV field format and generate different form for different format.