I propose a TKT_USER column as a "system-level" sibling (or even alternative) to the LOGIN column.¹
Please find the current state of the implementation in the tkt-ucard branch.

The main point is that TKT_USER would match U-card of the underlying ticket-change artifact.

I see the following shortcomings around the LOGIN column.

1. Duplication of information on /tkthistory pages in the default ticket configuration.
   The first line of each change already contains information about the user (in the form of a handy link, example) which is taken from the U-card.
   Subsequent lines of the same change also contain a "login: ..." line which match the previous (except for user "nobody").
   This creates unnecessary clutter. Perhaps it also creates confusion for non-tech-savvy or just less experienced users of Fossil (at least it did confuse me in the past).

2. Duplication of information in the artifacts (this is a minor issue though).
   LOGIN is recorded as J-card, but its value also equals U-card (except for "nobody").

3. To resolve the above issues, owner of a repository may want to amend the default schema so that there were no LOGIN column. Indeed it is possible to extract the necessary information from the EVENT table:
   

   SELECT event.user
   FROM ticketchng JOIN event ON tkt_rid = event.objid
   WHERE tkt_id=$tkt_id
   

   However, this also has a few issues.
   1. It requires more CPU and disk resources and doesn't allow to cache² (potentially non-trivial) computations involving the USER column.
   2. It is cumbersome and hard to write, debug and audit.

I think that the proposed TKT_USER column solves all the above issues and has no drawbacks. Functioning of the existing repositories won't be affected.³ Those who needs this feature (myself included) would benefit from the change.

What do you think?

---

1. ^{^} Unless otherwise noted, TICKETCHNG table is implied.
2. ^{^} Use of GENERATED columns with STORED flavor may be treated as caching.
3. ^{^} Please say if you think the opposite.

What do you think?

For what it's worth, i don't use the ticketing system often enough to have any strong opinions about it except for the opinion that it should be useful to those who use it (especially when those people write the code to make it so). If this small change makes it more useful for you then you'll get no objection for me.

I would like to merge tkt-ucard branch into trunk (within a day or so).
Are there any objections?

Are there any objections?

FWIW, i looked it over a couple of days ago and have no objections. It's a small, non-intrusive change.