Action/Trigger could benefit from low-hanging common case improvements

[Bill Erickson]

Evergreen 3.4

Proposing 2 A/T additions that should provide some benefit for common case scenarios, specifically when processing user-focused event definitions (notices, etc.)

1. Add a NULL-able 'usr' column to action_trigger.event. When an event definition has a “User Field”, stamp the user ID value on the events during the 'collecting' phase.

This should speed up the "Action Trigger User Log" query. (I thought there was an LP for this, but can’t find it). It also allows events to be more efficiently organized and processed via external scripts.

[ I also considered stamping the "group_field" value as a more generic solution, but not all user-focused A/T event defs are grouped, so we lose the benefit there. I could see adding both. ]

2. Add a require_usr_email field to event_definition to simplify administration and consolidate the check into a single place instead of across json filter files. Note this could be part of a validator or reactor, but enforcing the check during event creation means processing fewer events overall.

We can of course get by without either of these, but given the preponderance of A/T processing for most sites (I assume) is managing patron notices, a few optimizations could be helpful.

[Galen Charlton (gmc)]

The first point was addressed by the addition of context_user to action_trigger.event in bug 1207533.