Custom fields

[vgwidt]

I find myself needing a "Location" field, but adding it as a default field may not be appropriate. I could add it as a toggable field, but I think it might be better to just add custom fields. Either way, we need a system in which the user can customize these values.

Database minimum requirements

Create a table that lists the custom fields:

CREATE TABLE ticket_custom_fields (
    id SERIAL PRIMARY KEY,
    field_name TEXT NOT NULL,
    field_type TEXT NOT NULL, 
    is_select BOOLEAN NOT NULL,
    select_values TEXT[]
);

field_type would allow for type checking (i.e. int, text). is_select would make it a select input only. select_values would be default values. If is_select is false, but there are select_values, it would be a combobox.

Then, we need a table to store the actual field data for each field for each ticket:

CREATE TABLE ticket_custom_field_data (
    id SERIAL PRIMARY KEY,
    ticket_id INTEGER REFERENCES tickets(id) ON DELETE CASCADE,
    custom_field_id INTEGER REFERENCES custom_fields(id) ON DELETE CASCADE,
    field_value TEXT
);

Considerations

• Display priority should be allowed to be set
• Allowing for customizing element size may be necessary
• Should we allow it to be set as a default column in the ticket list, or leave that to user preferences?
• Should all custom fields be added to the ticket filter section?
• A lot of care will be needed for type checking and handling of changes or deletions of fields

[vgwidt]

Frontend will require settings routing to be reworked. I'd like to try a nested router for this.

[vgwidt]

Removing is_select in favor of having it being defined by the field_type. Also added order_index.

[vgwidt]

Would the implementation of custom fields affect how tags will be implemented? I like the idea of having both so that the user can choose what is appropriate. If tags had two levels (like Bookstack), it could eliminate the need for custom fields, but it would have to be implemented in a way that it could be shown as columns, filtered, and added to reports. So should we stick to adding custom fields then a more simple tag system like that of Github? Tags could still have subtags in this case, but without adding support for columns, reports, etc..