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.