Answers

• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  May 9

  When you do the import, each field is given a value, so a default would never apply, unless I'm misunderstanding?

  Allan
• pisisler Posts: 113Questions: 23Answers: 1

  May 10 edited May 10

  Right, that's actually something didn't feel right when implementing it. Because not all the fields have to be required. Usually, importing should allow leaving some columns un-mapped (i.e. empty). But this implementation doesn't have it and sorry I forgot to mention that I worked around by leaving an empty column in the CSV file and map the non-required fields to this empty column.

  This way I expected the default value could take over but now I come to realize that if importing forces to map each field, then it will never look for the default in the first place. But I think this is not right. Any way to work around this?

  I think the only viable option right now is to make columns for those columns with default values copied all over.
• pisisler Posts: 113Questions: 23Answers: 1

  May 10 edited May 10

  Here is another thing with importing CSV files: It doesn't ignore hidden fields which means it asks you to map CSV fields to hidden fields which in the end defeats the purpose of a field being "hidden".

  I tried filtering the field type by field.input().attr('type') but it didn't work. It returns "text" for text fields and undefined for all other types (select, checkbox, hidden etc.). As a temporary work-around, I am allowing the field to be shown only if they don't match the hidden fields' names.

  By the way, I can't comment on the Editor reference articles. It produces HTTP 500 error which could be seen in the console. I was to comment on hidden reference. There is a possibility of a flaw that should be noted when using hidden fields. The reference page gives an example setting the value of the hidden field on client-side; which means that anyone could alter it even if it's hidden. I think developers should be warned about it.
• pisisler Posts: 113Questions: 23Answers: 1

  May 15

  Anyone?
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  May 15

  Sorry - I'm struggling to keep up with the volume of support requests at the moment and I'm missing some now and then.

  On create, if you don't write a value to a field, it will take the default value. If it isn't, then it suggests something is being written to the field. Can you link to the page you are working on perhaps?

  By the way, I can't comment on the Editor reference articles. It produces HTTP 500 error which could be seen in the console.

  Doh - thank you. Added to the list .

  The reference page gives an example setting the value of the hidden field on client-side; which means that anyone could alter it even if it's hidden.

  Yes - hidden fields most certainly shouldn't be used for security. Anything from the client-side should be inherently untrusted. I'll add a note to the docs saying that it is trivial for someone to modify values in the hidden fields (or any field).

  Allan
• pisisler Posts: 113Questions: 23Answers: 1

  May 16 edited May 16

  On create, if you don't write a value to a field, it will take the default value. If it isn't, then it suggests something is being written to the field. Can you link to the page you are working on perhaps?

  On create, that's correct; but the question here is about importing. As you stated, importing doesn't respect default values because it assumes that you have a column in the CSV file for each column on the table. But this assumption is not right I think. For example my table could have 10 columns but the CSV file could have only 4. Nonetheless, the importing process maps the remaining 6 columns by rewinding the columns in the CSV file. (Like each column in the CSV file is mapped to the table columns twice.) There is no option to leave a table column un-mapped during import, not even the hidden ones.
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  May 16

  On create, that's correct; but the question here is about importing.

  An "import" is just a create - on line 28 in this example, you'll see that it calls create(). It then loops over all of the fields and sets the values. If you want it to be able to take a default value it should perhaps not loop over the fields, but rather the values selected for the mapping, getting each field as it goes, and ignoring those which are perhaps left as blank or some other "unselected" value.

  I think it should be quite possible to do what you want, but it will require a couple of tweaks from the code in the example.

  Allan