Show bulk upload source on entity detail page

[ktuite]

Closes getodk/central#583

Activity Feed

Entity create event from bulk upload:

I wanted to point out that an entity created from a submission looks like this:

In the submission case, there really is a separate source event to show. In the bulk entity upload case, it is literally the same event. We get the submission event off the entity create event and artificially insert it into the activity feed.

We could pretend there are two events, but I wasn't sure how the one event should be broken down or if it was even worth it.

Possibility (show size, too):

Conflict Tables

Basic Information

What has been done to verify that this works as intended?

Why is this the best possible solution? Were any other approaches considered?

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Does this change require updates to user documentation? If so, please file an issue here and include the link below.

Before submitting this PR, please make sure you have:

• run npm run test and npm run lint and confirmed all checks still pass OR confirm CircleCI build passes
• verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced

[ktuite]

(note to self) If we did want to show the file/upload size, here are some of my code snippets:

<template #size>
  <span class="source-size">({{ entry.details.source.size / 1000 }}Kb)</span>
</template>

  .source-size {
    font-weight: normal;
    font-family: $font-family-monospace;
    font-size: 12px;
    color: #777;
  }

"bulkSource": "File {name} {size} uploaded by {actor}"

[matthew-white]

If you click the link, are you scrolled to the entity.bulk.create event in the activity feed? I would think that scrollData() would have to change in EntityActivity. We know that the entity.bulk.create event always corresponds to the first version of the entity, so hopefully it'd be the same logic as for an entity.create event.

[ktuite]

I'm not going to add a test for this because I don't see a test for the entity.create case, but I did manually try it.

[matthew-white]

I might be completely misremembering, but isn't information about the source available on the entity response these days? It'd be pretty cool not to have to use audits and to get rid of this watchEffect() at some point in the future.

[ktuite]

It's available on the versions response but not the main entity response yet!

[matthew-white]

At first, I was thinking that we should use @transifexKey so that this message could be reused in EntityVersionLink. But thinking about it more, the two messages appear in different contexts that I could see affecting the translation. This is more like a sentence describing an event, while the message in EntityVersionLink is more like a noun phrase. That said, I do think it'd be helpful to add a comment here for translators.

[matthew-white]

Possibly related: I was looking at the release criteria, and I noticed that the text suggested for EntityVersionLink is subtly different from the text here (the same as the text in EntityVersionLink in this PR). In the release criteria, it's "upload", not "uploaded". I actually think "uploaded" reads better in EntityVersionLink than "upload", so I like it the way it is. But maybe the difference is getting at the different contexts in which the messages appear?

[ktuite]

Hmm, yeah, I see the distinction. I'll set the EntityVersionLink back to just "upload" for now just to match the release criteria, but we could tweak these things!