Import feature is ready - need testers :)

Where is the import feature ?!?! Can´t see anything… Expected it in "Tools"

Yes, took me a while also to find it .. go to menus and create a new menu item -- import ...

but as of now it will not work (at least here), since the sql update script to create a needed table was not included.

But... a frontend Menu-Item ?!?

At first i had the same thoughts and actually i expected it also under "tools" .. but the longer i think about it, the more i like the approach .

I always wanted to get away from the backend .. lets just see how it evolves. Sort of manual synchronization, etc ...

At this early stage we can influence the way import will be done. at least this is what i hope .. hahaha

Import from the front-end is not really a bad though.

The most important issue from my point of view is that it can be used also by the users to import records by themselfs, although if it goes that way i hope there are option to limit how many import records are allowed so that there are no problems with server hardware use.

Sackgesicht

Check if you have a table #__js_res_import_rows.

You are right, it is missing :(

Do you know if this is a universal import feature?

What field types will be NOT supported?

What field types will be NOT supported?

I do not know yet. GEO seams complicated. It have to contain data in special format and field have to understand where is lat, lng, address and so on.

Telephone is also complicated. it is hard to separate field into parts. The telephon should be in special format in order to be imported like

+countrycode[telephone]#[extension]

URL and Video also looks specific.

Fields like register, read also, records, parent, child are not going too.

All fields with files (image, gallery, uploads,..) are ok. Y can read instruction in import page. There have to be file packed with this name and few files have to be separated by coma.

All other fields looks like will work good.

parent, child are not going too

I would consider them quite important, since the source of the csv import might be different tables from other databases/applications.

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

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.

One of the things to request, after the core functionality is established, would be:

-- automated import from a (cron job) watch folder

To create some data from existing Cobalt/Might Resources for import testing, use following SQL queries:

1) Get the title from a section (replace xxxx with database prefix and use respective section_id)

SELECT

    title AS `Title`

FROM

    xxxx_js_res_record a

WHERE

section_id = 1

2) add a second column (text field)

SELECT

    title AS `Title`,

    (

        SELECT field_value

            FROM

                xxxx_js_res_record_values

            WHERE

                field_id = 1

                AND record_id = a.id

    ) AS `Text Field`

FROM

    xxxx_js_res_record a

WHERE

section_id = 1

3) add another column - child record

    (

        SELECT

            title

        FROM

            xxxx_js_res_record

        WHERE

            id = (

                SELECT

                    field_value

                FROM

                    xxxx_js_res_record_values

                WHERE

                    field_id = 25

                    AND record_id = a.id

                )

    ) AS `Child Record`

and so on ... :D

I've tried everything I have thought of, which hasn't been much, and it will not let me click next after selecting my CSV. Is it still not yet working for everyone else as well? My version number says 8.227

I do not know yet. GEO seams complicated.

I think, at least "Address" data is important for many users. Since Cobalt has this multi-data location field, it seems obvious to support it as well...

Maybe explain and describe the special format before import? So, the import file already has this format.

(Personally, i tend to use single fields. We already had some discussions about separate fields and utilize that data in location field. That was possible in ME Resources and i liked it)

Derrick,

this version can not import. A database table is missing (#__js_res_umport_rows). I created the missing table myself and it will import the csv into the table, but then there are new problems coming up. It seems not all needed info (by a later query) was inserted by the insert query (section_id and user_id).

Better we wait for a new installer ...

@pepperstreet

Yes the geo field should be there as well. I have quite a good idea how to solve this (even with geo coding and reverse geo coding as optional helpers to make it more sophisticated than ordinary field to field matching).

Lets see first how the core import will work and then discuss the "refinements".

A database table is missing (#__js_res_umport_rows).

It should be there in last file I sent.

A database table is missing (#__js_res_umport_rows).

Is it still not yet working for everyone else as well?

Please check id table #__js_res_import* was created.

226

GEO seams complicated. It have to contain data in special format and field have to understand where is lat, lng, address and so on.

How about a drag and drop matching.

Cobalt TYPE fields which store more information will be displayed as accordion. When opening

the accordion all individual geo fields (same info as in an entry form) are displayed as drop container and on the other side all fields from CSV can be dragged to match with the destination field (or subfield in case of a GEO field). Then it will processed the same way as edit or create the record.

See example:

it is even can update old records and save configuration. So next time you upload CSV only price or availability will be updated for all products for example.

How about updating already existing records?

Updating/Synchronizing based on a unique field content.

Example: I have a type with a unique titel and this titel is also part of the CSV fields, the import will just update the selected fields.

Same should be possible if i have a field in the type which is considered unique, like serial number.

Important part of import would be an import log file for checking/error messages or in case of updating records a "compare" log. (remember my excel import logs when we imported files)

How about updating already existing records?

Yes this will work. When you import the same CSV second time it wil update all old records. It saved ID field of CSV and IDs conversion array. So next import it updates old records and insert new.

How about updating already existing records?

How about a drag and drop matching.

D&D is good. I think it is best for usability. But right now i want to accomplish main process and later I may advance UI. But Idea is good. I understood princip. Every field have to draw it's own form. I'll make that change. Not D&D but basically the same idea.

Initial Commnets:

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

Every field have to draw it's own form. I'll make that change. Not D&D but basically the same idea.

Yes same as it is now would be good enough.. just a select box which will offer all import fields from csv,