Importing into custom fields?

[rootameen]

Hello!

I'm really excited about custom fields. I've set them up and they are doing wonders.

Now, I want to re-import my data with custom fields in mind, I tried to figure out how the sample import file you have is structured against fields but I couldn't relate the two.

Any hints on how I can do that? Thanks!

[uberbrady]

Oh wonderful! Is there anything in particular you're mapping with custom fields? I'm curious to hear people's use-cases.

The import issue you're talking about is one that I know @snipe has discussed with me. Right now, the import structure is 'fixed' - you have a sample format, you fill in the blanks. With the new custom fields feature, we have the potential for starting to convert non-custom fields into custom fields (mostly so people can remove them). And one of the steps in there would be to also start supporting them somehow in import. As we talked through the feature, it started to sound complicated.

The problem is basically that the fieldset is determined by the Model (as you have probably worked out since you've been using them). And the importer system is supposed to dynamically create models as its running through the import. So I don't know exactly how we'd dynamically start creating fieldsets - but a couple of thoughts come to mind:

1) Create an 'importer' fieldset which is a superset of all the fields. Later, the end-user can go back through and start assigning specific fieldsets to the models that have been instantiated. This is a genuinely horrible idea. But it's easy.

2) Look at the custom fields being specified in the import, and for every new combination of fields that comes in, create a new fieldset. This really only works (in my opinion) with renamable fieldsets - another feature we don't have. Anyway, here's an example of how I was thinking about it:

Asset	Model	Custom Field 1	Custom Field 2	Custom Field 3
1	A	NULL	NULL	NULL
2	B	Value	NULL	NULL
3	C	Value	Value	NULL
4	D	Value	NULL	Value
5	E	Value	Value	Value

In this example, Asset 1 would get a NULL fieldset, Asset 2 would get "Fieldset 1" which is defined as containing Custom Field 1, Asset 3 gets "Fieldset 2" ... and you get the idea. In my example, each asset would end up generating its own fieldset (Except for Asset 1, which has no fieldset).

I guess the algorithm boils down to: run through the entire import file, picking out unique models and associated custom fields with them. The Model will get dynamically created with a superset of all of the custom fields that the importer has found when running through the file. Any field that shows up only 'sometimes' can get added as 'not required'. Whereas any field that shows up on every single asset (of that particular model type) could get added as 'required'.

3) Require the models/custom fields to be pre-set-up before you run the import (this sounds like it hooks up with your use-case).

It sounds to me like number three would solve your problem, whereas I think @snipe would probably prefer number two.

Needless to say, this one ends up being kinda hard :( I don't know what the right thing to do here is. Let's see what @snipe thinks.

[rootameen]

Woah! Thank you for taking the time in writing all of these details @uberbrady!

I'm still playing around with the solution to understand it and see what it's capable of before doing something crazy. But with custom fields I think the sky is the limit.

The scenario I'm doing right now is to document Lab Environments. Accessories and Consumables aren't doing much for me yet, but I'm still thinking how I can utilize them. Reason That Custom Fields are very useful for me is because I need to store details about IP Addresses, Gateways, OS, and other relevant information. Pretty much all assets I have will have the exact same custom fieldset which also makes it easier - I think - to figure out how can I import data. I currently don't need the importer to create any fieldsets or fields.

So If I have a fieldset called LabMachine that includes IP,G/W,OS as fields, and I want to import my data into these fields, what would be the better approach of doing that? I was thinking even if the importer isn't meant to work with custom fields yet, to use a db query that inserts new rows into the assets table since I can see my custom fields there. But the importer would be more beneficial for the project than workarounds.

One more thing I noticed, The importer (in it's current state, without custom fields) seem to ignore any fields you leave empty even if they are mandatory. I was able to import data even though I didn't specify Asset Models or Categories. I'm not sure if that would affect anything regarding custom fields.

[snipe]

I'm okay with option 3 as a first-step. Ideally, I'd like us to get to option 2, but I think option 3 will get us to a place where users can start importing custom fields. We can always refine it over time and move closer towards option 2.

[drewrowland]

We're an education institution just starting to use Snipe. So far so great! We have around 700 devices that have three custom fields (Floor, Cart Letter, and Computer Number). We would love the ability to import custom fields, but we're going through by had at this point and inputting the info, which is fine as well since once we have it done it'll be easier to keep up-to-date unless we move a whole cart, which does happen somewhat often.

If the Fieldset is assigned an ID it would be just as easy to be able to put that ID into our import sheet and then specify the custom fields after that. If that would work, I don't know. I think there would need to be a null option in case something does not fit the fieldset, but needs to be imported.

Let me know if you need anymore detail!

[varjen]

Would it be possible to make the import feature slightly intelligent? What if it reads the DB, before it actually runs the import, to check for any new custom fields?

This is a very interesting matter for me as we are just in the process of adapting snipe for our dept.

If i can't find any other method im just going to have to make a custom import script, but i rather not.

While im at it, as this has a connection to the subject, has anyone ever tried making an update script? We are running zenworks for pc management and i would just love to make something that autoupdates the inventory say, every 24 hours or so, without making copies of everything. Again, i guess i could make it, but if someone already has.... (im still reading through the issues so i might find something yet.)

[PMarkovski]

+1 When can we expect to import custom fields ?

[hyggja]

+1

[faisal-mirza]

+1 Really like the tool and would greatly appreciate being able to import custom fields

[varjen]

I have made a proof of concept importscript that imports into custom fields, so it CAN be done. The trouble is that you have to make a really tricky and clever script if you are not a coder yourself. The cause of this is of course that the import script cannot forsee the name users give their custom fields, hence it cannot import into them.

My next test, if i get the time, is a more flexible script that reads the DB for customfields and asks the user which ones to include in the import. It CAN be done, it's just a little...tricky... If i had any skills in UI's i would love to make the import webbased.

[snipe]

Of course it can be done, we just haven't had a chance to do it yet. As you say, it's tricky, and if not done correctly could be enormously brittle, mangling people's data very badly. What I would like to do for imports is to have a confirmation screen, either reading the import into a temporary table that allows for fixing mapping, etc, or just using an in memory array, although that could get ugly with very large files.

[varjen]

I had this idea, if it works that is, to first ask the DB which fields it has, the custom ones are easy to find and all… Then ask for the CSV, read the first two lines and ask the user to match columns or at least check if they already are matched, then start the import.

It’s not done easily though and as stated, it might be very brittle.

Från: snipe [mailto:notifications@github.com] Skickat: den 19 april 2016 13:58 Till: snipe/snipe-it Kopia: varjen Ämne: Re: [snipe/snipe-it] Importing into custom fields? (#1450)

Of course it can be done, we just haven't had a chance to do it yet. As you say, it's tricky, and if not done correctly could be enormously brittle, mangling people's data very badly. What I would like to do for imports is to have a confirmation screen, either reading the import into a temporary table that allows for fixing mapping, etc, or just using an in memory array, although that could get ugly with very large files.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/snipe/snipe-it/issues/1450#issuecomment-211880699 https://github.com/notifications/beacon/AM29rUJZYgG0yfHgV5uBzAjn-GuxoQcQks5p5MMxgaJpZM4GvncO.gif

[snipe]

Importing custom fields was added in v3.3 or 3.2. https://snipe-it-manual.readme.io/v3.3/docs/importing-assets#importing-custom-fields