Adding evidence to badge instances

[ghost]

This adds the ability to specify an evidenceUrl when awarding a badge. This will appear in the instance's assertion under the new field "evidence", as described by the specification.

[brianloveswords]

Seems reasonable to me, handing off to @cmcavoy to hit the merge button.

[ottonomy]

👍 Thanks, @christensenep -- We'll start using this right away.

[cmcavoy]

Hey @christensenep shouldn't these evidence objects go in the evidence table? If evidence is created as part of an application, we're handling it one way, then differently if it's attached here. Shouldn't they both use the same system?

[ghost]

Well, I thought this was a little bit different than the evidence that comes with an application. For one thing, there can be multiple evidences per application, and each evidence can have a "reflection" attached to it. But the OBI spec has the "evidence" field as a simple URL, so I think they're kind of different.

I initially was doing something fairly complicated where you'd send along which application was involved with a badge award, and it would duplicate the evidence that was in that application (remember, badgekit API does not associate badge awards with application reviews, and has no idea what application resulted in a given badge award, if any).

But then I realized that the OBI spec just wants a single URL for evidence, whereas we can have an arbitrary number of evidences in an application. So I figured that API consumers could decide what they want to link to (possibly a url that displays all the evidence submitted by the user in the first place).

If there's some specific implementation you have in mind, though, let me know.

[ottonomy]

I'd like a method that I could use either for badge issuing or claim code
creation, actually. :-)

[ottonomy]

Have you guys considered using a document store style database for badge objects: assertions, claim-codes-for-badges, badgeclasses, issuer organizations, evidence?

It would be a huge change, but in a lot of ways, I think a datastore approach to this information might be a better fit with what is getting stored.

[brianloveswords]

@ottonomy openbadger did and it was a nightmare on many levels. It turns out there are more relationships than one would anticipate and having to do those "joins" in userland was a performance anchor (talkin' bout multi-second response times). It's certainly possible that we just don't know how to optimize mongo, but we do know how fairly well how to optimize mysql.

[cmcavoy]

The spec says,

URL of the work that the recipient did to earn the achievement. This can be a page that links out to other pages if linking directly to the work is infeasible.

So if someone submits multiple pieces of evidence through an application, all of those links should show up on a single page, right? How are we displaying evidence urls submitted through the application process? Unless I'm wrong, it doesn't look like we're attaching them to our hosted assertions...which is a whole different issue. But, assuming we were attaching the url's to the assertions, shouldn't we use that system instead of adding a new column to the badgeinstance table?

What if we extended,

const Evidence = db.table('evidence', {
  fields: [
    'id',
    'applicationId',
    'url',
    'mediaType',
    'reflection'
  ],
});

to include a link to the badgeinstance (if the badge is awarded)

const Evidence = db.table('evidence', {
  fields: [
    'id',
    'applicationId',
    'badgeinstanceId', # <-- new column
    'url', #<-- store the evidence url here
    'mediaType', #<-- not used if it's a direct evidence submission
    'reflection' #<-- not used if it's a direct evidence submission
  ],
});

Something about having evidence url's in two different places depending on the way the evidence got into the system bothers me.

What say ye?

[abbycabs]

@simonwex here's the feature I was talking about!

[simonwex]

Thanks, @acabunoc! I'll add this to the list.