Snipe-it: Custom field is not generated when the field name is similar in Korean.

[croshine]

Expected Behavior (or desired behavior if a feature request)

When I create a custom field in Korean such as "입고일"(Stocked Date).
Then I can create a custom field "출고일"(Reserved Date).

---

Actual Behavior

I created a custom field in Korean such as "입고일".
Then I try to create a custom field "출고일".
But it was not working with a message "Field was not created, please try again."

So I try to insert the custom filed into MySQL manually.
It was working, but causes another problem.

Value of the two fields is same always.
Changing one field, the other field also changes.

---

Please confirm you have done the following before posting your bug report:

• [X] I have enabled debug mode
• [X] I have read checked the Common Issues page

---

Please provide answers to these questions before posting your bug report:

• Version of Snipe-IT you're running : v3.3.0-16-ge52a0f6
• What OS and web server you're running Snipe-IT on : CentOS 7.1 and Apache/2.4.6
• What method you used to install Snipe-IT (install.sh, manual installation, docker, etc) : install.sh
• If you're getting an error in your browser, include that error
• What specific Snipe-IT page you're on, and what specific element you're interacting with to trigger the error
• If a stacktrace is provided in the error, include that too.
• Any errors that appear in your browser's error console.
• Confirm whether the error is reproduceable on the demo.
• Include any additional information you can find in app/storage/logs and your webserver's logs.
• Include what you've done so far in the installation, and if you got any error messages along the way.
• Indicate whether or not you've manually edited any data directly in the database

[uberbrady]

This is an excellent bug report; thank you.

As a workaround, try and see if you can find a way to append something unique - like, try this -

입고일_1
출고일_2

The problem is, mysql field names need to be in ASCII, and we translate anything not a-z, A-Z, 0-9 into _. So that means the custom fields system will translate your fields into _ _ _ or maybe _ _ _ _ - which easily conflicts, as you can see.

The balance we're trying to weigh here is that it's much easier to administer the database if your custom field "Reserved Date" shows up in the database as _snipeit_reserved_date - but it is terrible for non Latin scripts, and that's a flaw I made when I made it.

Having looked into it, and playing around with it in MySQL 5.6, it looks like that restriction on names is unnecessarily strict -

mysql> create table test (💩   text);
ERROR 1300 (HY000): Invalid utf8 character string: '\xF0\x9F\x92\xA9'
mysql> create table test (출고일 text);
Query OK, 0 rows affected (0.04 sec)

mysql> insert into test values ('hi there');
Query OK, 1 row affected (0.01 sec)

mysql> select * FROM test;
+-----------+
| 출고일    |
+-----------+
| hi there  |
+-----------+
1 row in set (0.00 sec)

So I can probably change the translation algorithm going forward. Also while I'm in there I need to handle #1683 - setting a maximum limit, and still trying to keep the names unique.

The migrations are going to be awful for this, though. That, I am definitely not looking forward to.

[uberbrady]

I _will_ have to prevent users from creating field names with Emoji in them, though. (As evidenced by the first test failing).

[uberbrady]

(Memo to self) MySQL schema name limits - and lengths - are here: http://dev.mysql.com/doc/refman/5.5/en/identifiers.html

It looks like it's worked this way since at least 5.5

[croshine]

uberbrady is uber buddy!
Many thanks :D

[croshine]

It's been four months since i reported the bug.
How is it going?

[snipe]

When we have progress to report, we will update the ticket.