Open vgwidt opened 1 year ago
Frontend will require settings routing to be reworked. I'd like to try a nested router for this.
Removing is_select in favor of having it being defined by the field_type. Also added order_index.
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..
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:
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:
Considerations