SF-2392 Add event metric logging

[pmachapman]

This PR adds support for logging events via the [LogEventMetric] attribute.

To access it, a button is added to the serval admin page. Although permissions are granted for project admins to view the event log, a link is not provided in the UI until we are ready to expose it to a wider audience.

This PR is intended to be a minimal MVP leaving enough scope for us to expand in the coming months. Perhaps the bulk of the new code is unit tests for existing functionality that did not have unit tests.

See https://github.com/sillsdev/web-xforge/wiki/Event-Metric-Logging for documentation on how this feature works and how to use it.

---

This change is 

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.96%. Comparing base (4b5a01c) to head (87e733b).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2894      +/-   ##
==========================================
+ Coverage   80.89%   81.96%   +1.07%     
==========================================
  Files         533      545      +12     
  Lines       31212    31485     +273     
  Branches     5060     5083      +23     
==========================================
+ Hits        25248    25808     +560     
+ Misses       5217     4933     -284     
+ Partials      747      744       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kylebuss]

I'm not certain that both the event-metrics.component and event-metrics-log.component are necessary. Is there a reason for two separate components for this?

Reviewed 5 of 11 files at r1, 5 of 10 files at r2, 8 of 11 files at r3, 2 of 8 files at r4, 17 of 21 files at r6, all commit messages.
Reviewable status: 37 of 41 files reviewed, 9 unresolved discussions (waiting on @Github-advanced-security[bot] and @pmachapman)

---

src/SIL.XForge.Scripture/ClientApp/src/app/event-metrics/event-metrics-log.component.ts line 35 at r6 (raw file):

  constructor(
    noticeService: NoticeService,
    private readonly i18n: I18nService,

Will this be needed since it's an admin only screen?

Code quote:

private readonly i18n: I18nService,

---

src/SIL.XForge/EventMetrics/EventScope.cs line 1 at r6 (raw file):

namespace SIL.XForge.EventMetrics;

Should we consider adding Users scope? For SF invites and roles?

[pmachapman]

I'm not certain that both the event-metrics.component and event-metrics-log.component are necessary. Is there a reason for two separate components for this?

This PR is still work in progress. I am still writing this (and other) areas of the code.

Dismissed @Github-advanced-security[bot] from 7 discussions.
Reviewable status: 37 of 41 files reviewed, 2 unresolved discussions (waiting on @Github-advanced-security[bot] and @kylebuss)

---

src/SIL.XForge/EventMetrics/EventScope.cs line 1 at r6 (raw file):

Previously, kylebuss (Kyle Buss) wrote…

Should we consider adding Users scope? For SF invites and roles?

These can be added if needed.

---

src/SIL.XForge.Scripture/ClientApp/src/app/event-metrics/event-metrics-log.component.ts line 35 at r6 (raw file):

Previously, kylebuss (Kyle Buss) wrote…

Will this be needed since it's an admin only screen?

Yes, as project admins will access it.

[kylebuss]

src/SIL.XForge/EventMetrics/EventScope.cs line 1 at r6 (raw file):

Previously, pmachapman (Peter Chapman) wrote…

These can be added if needed.

nit Can the EventScope be renamed to AppComponent or AppFeature? I think this would be useful for the Help Videos and would like to use the enum.

[kylebuss]

src/SIL.XForge/EventMetrics/EventScope.cs line 1 at r6 (raw file):

Previously, pmachapman (Peter Chapman) wrote…

Do you still need this functionality?

I don't think so, but it might not be a bad idea to make it more universal if we need something in the future?

[pmachapman]

I don't think so, but it might not be a bad idea to make it more universal if we need something in the future?

Let's wait until we have a solid requirement. We can always rename/refactor in future.

[kylebuss]

Excellent work on this Peter!

There are a couple of things that could make this better but they might be for a different time. No need to work on them now unless you think they should be included in this PR.

1. While offline the Event Log page does not load and should say that Log is not available when offline or we need to make the log available offline.
2. It'd be nice to have a filter on the column headers.
3. We might need to discuss adding an Admin section to the left navigation to improve overall navigation as we add more features that are for elevated access users.
4. Author column - I like the thought of this but if we did add filters searching for "Me" seems odd. Might also make sense to have a separate Date column.

Reviewed 9 of 14 files at r8, 2 of 4 files at r9, 2 of 8 files at r10, 2 of 21 files at r12, 1 of 19 files at r13, 39 of 39 files at r15, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @pmachapman)

---

src/SIL.XForge.Scripture/ClientApp/src/app/event-metrics/event-metric-dialog.component.html line 13 at r15 (raw file):

      <h3>{{ t("parameters") }}</h3>
      <div>
        <pre>{{ data.payload | json }}</pre>

When I ran a draft the TrainingScriptureRanges[] did not appear in the details dialog.

Code quote:

<pre>{{ data.payload | json }}</pre>

---

src/SIL.XForge.Scripture/ClientApp/src/app/event-metrics/event-metrics-log.component.ts line 40 at r15 (raw file):

  private pageIndex$ = new BehaviorSubject<number>(0);
  private pageSize$ = new BehaviorSubject<number>(50);

nit I like the idea setting this to 10. I think it provides a cleaner look.

Code quote:

private pageSize$ = new BehaviorSubject<number>(50);

---

src/SIL.XForge.Scripture/ClientApp/src/app/event-metrics/event-metrics-log.component.ts line 155 at r15 (raw file):

      StartPreTranslationBuildAsync: 'Start draft generation',
      SyncAsync: 'Start synchronization with Paratext'
    };

I think this is fine for now, but we will want to localize these. Is there a way to get SetIsValidAsync to show valid or invalid based off of the results value?

Similar for enabled/disabled to show on or the other based on which was set.

Code quote:

    const eventTypeMap: { [key: string]: string } = {
      CancelPreTranslationBuildAsync: 'Cancel draft generation',
      CancelSyncAsync: 'Cancel synchronization with Paratext',
      SetDraftAppliedAsync: "Updated the chapter's draft applied status",
      SetIsValidAsync: 'Marked chapter as valid/invalid',
      SetPreTranslateAsync: 'Set drafting as enabled/disabled for the project',
      SetServalConfigAsync: 'Manually update drafting configuration for the project',
      StartBuildAsync: 'Begin training translation suggestions',
      StartPreTranslationBuildAsync: 'Start draft generation',
      SyncAsync: 'Start synchronization with Paratext'
    };

[pmachapman]

Definitely in a follow up PR. I want to have the event log used a bit so we can figure out what changes we want to it.

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @kylebuss)

---

src/SIL.XForge.Scripture/ClientApp/src/app/event-metrics/event-metric-dialog.component.html line 13 at r15 (raw file):

Previously, kylebuss (Kyle Buss) wrote…

When I ran a draft the TrainingScriptureRanges[] did not appear in the details dialog.

Done. Thank you for finding that bug!

---

src/SIL.XForge.Scripture/ClientApp/src/app/event-metrics/event-metrics-log.component.ts line 40 at r15 (raw file):

Previously, kylebuss (Kyle Buss) wrote…

nit I like the idea setting this to 10. I think it provides a cleaner look.

Done.

---

src/SIL.XForge.Scripture/ClientApp/src/app/event-metrics/event-metrics-log.component.ts line 155 at r15 (raw file):

Previously, kylebuss (Kyle Buss) wrote…

I think this is fine for now, but we will want to localize these. Is there a way to get SetIsValidAsync to show valid or invalid based off of the results value?

Similar for enabled/disabled to show on or the other based on which was set.

Yes, definitely localize after we have used it for a bit and figured out how useful the descriptions I gave are.

I have added a block to show custom values based on what was set.

[kylebuss]

Reviewed 7 of 7 files at r16, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @pmachapman)

[kylebuss]

Reviewed 6 of 6 files at r17, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @pmachapman)