Closed Bug 910892 Opened 11 years ago Closed 6 years ago

allow users to save badges to backpack

Categories

(support.mozilla.org :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: willkg, Unassigned)

References

Details

(Whiteboard: u=contributor c=badges p= s=2013.backlog)

Bug #896137 adds badge infrastructure to Kitsune.

That code allows Kitsune to manage all badges and awards. However, we want to be able to let users save badges to their backpack.

This bug covers figuring that out.
Blocks: 897057
Priority: -- → P2
Target Milestone: --- → 2013Q3
One other thing that needs to get figured out in this bug is award revocation.

Let's look at this contrived example:

1. We add code to Kitsune to award a badge to anyone who replies 10 times in the support forum.
2. Bobby games the system and spams 10 replies to the support form.
3. The code awards Bobby the badge automatically.
4. Bobby saves the badge to his backpack.
5. Someone notices the system gaming and the award is revoked in Kitsune (i.e. the Award instance in our db is deleted or whatever)

What happens at this point with the backpack? Is it the case that the backpack verifies the badges with SUMO every time they're shown?

I'm pretty sure there's a revocation process, so we just need to make sure we know what it is and make sure our system can handle it and/or write up a bug to implement whatever it is we need to implement.
Another thing we should probably figure out with this bug is whether we need to store baked award images. I'm pretty sure the "image" property of the Award class is for baked award images that have the assertion metadata in them. Will we need to bake images and store them?
Q3 is over... => Q4
Target Milestone: 2013Q3 → 2013Q4
No longer blocks: 897057
To update this bug with recent discussions:

* Roland is looking into the revocation API
* If it's easy to do we should implement that. If it's not that easy, forgoing that for now seems reasonable. Doesn't seem like scamming SUMO with undeserved badges would be a huge issue. And if it does become a big issue, we might need to change how we are awarding them automatically anyway.
* This bug needs UX love. Specifically: What does the process for transferring 1, a few, a lot of badges to your backpack look like.
It looks like the simple way of pushing badges to the backpack is using the Issuer API:
https://github.com/mozilla/openbadges/wiki/Issuer-API#using-the-api

It appears that multiple badges can be pushed at once:
    OpenBadges.issue([url1, url2], function(errors, successes) { //do something });


Something that we might want to keep track of is which badges have been pushed already. I'm not sure if the successes parameter in the callback above might help us here? Or maybe it isn't important to know which badges have been pushed and we can let them keep on pushing them forever and ever?
I'm not sure we need to keep track of which badges were pushed. UI-wise it might get annoying to have a "push to backpack" button for every award, but I think there are other ways to deal with that rather than have to maintain bookkeeping which might have problematic edge cases.
Hi WillKG and :r1cky:

Based on my research which consists of reading:

1. the current issuer api
https://github.com/mozilla/openbadges/blob/development/docs/apis/issuer_api.md :
"Since authentication is done via BrowserID, which opens in a pop-up window" where BrowserID == Persona

2. accepting and  pushing my mozilla summit 2013 badge to the mozilla backpack

it appears that the mozilla backpack requires persona.

And IF I am correct and 
3. there is no easy way of mapping SUMO ids or SUMO id email addresses to Persona ids 

THEN

4. we have no easy way of pushing SUMO badges to the Mozilla backpack until SUMO transitions to Persona

Am I right?

Or is there an automatic, semi-automatic or kludgy method we can use to push SUMO badges to the Mozilla backpack without waiting for Persona to fix their bugs on Firefox OS?
oh as for revocation  all i could find was:
https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md

"To mark a badge as revoked, add an entry to the resource pointed at by the IssuerOrganization revocationList URL with the uid of the badge and a reason why the badge is being revoked."

i don't think this is a big concern.

I think all we need to do is to file a separate bug requesting a development of a simple revocation script or a simple manual revocation tool that can be invoked from the django admin back end, does this sound good?
This bug is in the backlog and that's why no one has worked on it and it seems to be languishing.

I'm pretty sure we don't have to map sumo ids to persona ids. Pretty sure what Ricky said in comment #6 is right.

I don't understand what you're talking about in comment #10 regarding revocation. However, I'm not too worried about it. If django-badger can't already handle revocation, we'll add that functionality. From what I understand, revocation is pretty straight-forward.
:willkg thanks for responding the day after American turkey day :-)  Step away from the keyboard until December 2, 2013!

1. let's get this bug fixed in Q12014 so SUMO can be a full fledged Mozilla open badge issuer

Kadir, ricky and willkg: Could we please get this on the roadmap to be fixed in Q12014 and out of the backlog? After the summit i've had many folks ask why aren't our badges showing up in the backpack along with their Mozilla Summit 2013 badge. It doesn't make sense for SUMO badges not to show up in the Mozilla backup.

2. "I'm pretty sure we don't have to map sumo ids to persona ids. Pretty sure what Ricky said in comment #6 is right."

yay! it wasn't obvious to me from reading comment #6 that we don't have to map userids. Glad to hear we don't. To me this mapping was the only showstopper. So no mapping means no showstoppers means we can get this bug fixed in Q12014. Am I right or are there other showstoppers?

3. "I don't understand what you're talking about in comment #10 regarding revocation. However, I'm not too worried about it."

I don't understand it either :-). Sounds like you host some badge metadata at a known URL including revocation if the badge was revoked and that forms an assertion for a badge. But I don't understand how the Mozilla backup server finds out about the revocation assertion. But like you I am not worried. Again Kadir/Will/Ricky if you want me to file a bug about revocation, let me know and I will.
Moving 2013Q4 bugs to the Future since we didnt care enough about them in 2014Q1.
Target Milestone: 2013Q4 → Future
Blocks: 979538
See Also: → 1257352
I'm pretty sure the backpack is done. At a minimum, badges.mozilla.org is done. I'm going to WONTFIX this.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.