I think these changes are OK, I think they can be merged to trunk. What do you all think?

FWIW, it looks good to me and provides a useful capability with minimal new code. IMO, merge it, but let's wait a few days for objections before doing so.

A few days are gone, anyone having objections to merge this tomorrow?

Are these changes (like settings priority, subsystem, private contac fields) hardcoded or changes to TH1 defaults?

If hardcoded, that would break customized setups where there are no such fields in the ticket setup. Stuff does already break if there is no column 'title' in the ticket setup, as this is hardcoded in C at some places ... no more of these, please!

Filtering out the private contact is hardcoded in C, where it was set in the first place. 'Submit and New' has parts changes in TH1 and parts in C (to actually make it work both parts are needed). The submenu and inclusion of priority and subsystem in new tickets is done in the default TH1. Actually I had first made the submenu in C, then realized that as Th1 it allows more configurability and changed it.

EDIT: to be clear, the private contact was always in the form, but previously it would be filled with the contact of the cloned ticket, which didn't seem right. You can edit away private contact still. I think nothing of these changes should break customized TH1 forms. If you remove private contact from the TH1, it works as the C code only removes the copy of the contact from the cloned ticket and allows the (already existing) code to fill the template with the current users email.

Also, what breaks if the title column is removed? Maybe that can be fixed.

My workaround is to declare a virtual column 'title' in the 'ticket' table.

IIRC, the offending parts are:

• the ticket-title-expr setting, which contrary to its name can not be an expression like eg. substr(some_other_field,1,20) but must be a pure column name (default = title). Not having title (or another column as set accordingly) make rebuilding the ticket table crash, due to this part of the code.
• the code here breaks the /ambiguous webpage which is used be eg. /info. It has a hardcoded query on title, which must exist in TICKET but not in TICKETCHNG (then the query fails because title in the select is ambiguos by itself). So when removing 'title' from the TICKETS table, this breaks ambiguous /info/ pages even if the ticketsystem is not used at all ...

I noted this in a ticket. I want to explore the issue. I cannot promise that I will fix it, but I will try to understand what happens here. The ticket is to track this.

Or instead just document that 'title' is mandatory (as is tkt_id ...) in the ticket table ... and that it can be a virtual column, eg something along

title TEXT GENERATED ALWAYS AS ( printf('%s %s',other,columns,...) ) VIRTUAL,

which also makes (the not exactly working as called) ticket-title-expr superfluous

There might be a third one: The construction of the FTS5 search index could depend on hard-coded 'title' as well. By that time, I already had the virtual column in place ...

I think my answer covered your concerns and I think the changes in the branch don't create more issues that you fear. So if you or others don't raise any other concerns, I still would go ahead and merge this.

Yes, I did test that branch with one of my (quite heavily customized) tickets setups and no additional problems found

Thanks for your tests. I merged the branch.