[Koha-bugs] [Bug 35625] Add support for system flag to additional fields

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35625

--- Comment #10 from Pedro Amorim <pedro.amorim at ptfs-europe.com> ---
Hey, adding my 2 cents here in what I hope to be a constructive addition.

(In reply to Jonathan Druart from comment #9)
> The purpose of this table/ft was to add specific data. Flagging a fields as
> "is mandatory for the system to work correctly" is wrong by design IMO. It
> should be a column in the original table.

I can definitely see where this argument is coming from, although I don't 100%
agree with it being wrong by design. This is still specific data, it's just
additional fields that Koha's code will rely on and can't be removed.

Some of the alternatives here are:
- Add the columns page_url and biblio_id to the ticket table, even though only
ticket.source=catalog will use the biblio_id column and only
ticket.source=opac_problem will use the page_url, this would get more and more
confusing and hard to maintain as we go in the future (i.e. every new single
type of ticket will potentially require new niche fields for their own).

- Add a new 'tickets_attributes' table (and have this be the 4th relational
metadata table we have in Koha, alongside additional_fields, patron_attributes
and illrequestattributes. This would allow for a ticket of source=catalog to
have the biblio_id and the ticket of source=opac_problem to have the page_url,
without adding new columns to the table and making it flexible enough for
future ticket types (sources). The problem here is that all this logic already
exists in additional_fields.

- Have a 'other_stuff' column in the tickets table that would store a json
object that could store whatever in it and logic would handle what it wants to
retrieve/store depending on the ticket.source (like plugin_data). This is not
ideal either.

----

The advantages of having an additional_field:is_system are:
- This is_system additional_field will automatically benefit from all the
features from additional_fields (it may potentially be an authorized value
list, repeatable, searchable, filterable, and so on) AND it would not pollute
the tickets table (or any other table that would need to make use of this) with
niche fields only used by some instantiations of the table, and not others.
- Existing code from additional_fields is reused, thus any future fixes and
enhancements also benefit this is_system additional_field. Whereas in any of
the alternatives above if you need a specific field to be searchable on the
datatable for example you will need to update the data table code. By using the
additional_fields with is_system, the programmer just needs to set the field as
searchable and nothing else needs to be done, again, benefiting from the
additional_fields native features.

-- 
You are receiving this mail because:
You are watching all bug changes.