Simon Coggins

Hi Frankie,

1. I think the page you are looking for is My Profile > My Badges. This is where a user goes to see all of their badges and control the visibility of them to others.

If a user makes some of their badges public they will appear on the user's profile. There is also a "My Badges" block which users can add to the "My Home" section.

2. The problem seems to be that the badge is "Active", and active badges are locked down to prevent changes. If you deactivate the badge (button at the bottom of the overview page or green dot from the index) you should be able to change the image (as long as it hasn't yet been earned by anyone).

Here's what the help says:

Badge status determines its behaviour in the system:

• ACTIVE – Active badge means that this badge can we earned by users, but it has not been issued yet. When a badge is active, its criteria cannot be changed.

• INACTIVE – Inactive badge means that this badge is not available to users and cannot be earned. Criteria of an inactive badge can be changed.

• ACTIVE AND LOCKED – Badges with such status can be earned by users, but they have been issued in the past. Therefore, their criteria are locked and cannot be changed.

• INACTIVE AND LOCKED – Inactive badges cannot be earned by users and their criteria cannot be updated.

Badges are set to locked automatically once they have been issued to at least one user. Unlike active or inactive, this property cannot be manually changed. If you need to modify details or criteria of a locked badge, you can duplicate this badge and make all the required changes.

Why do we lock badges?

We want to make sure that all users complete the same requirements to earn a badge. Currently, it is not possible to revoke badges. If we allowed badges requirements to be modified all the time, we would most likely end up with users having the same badge for meeting completely different requirements.

That's the reasoning behind it, but I think this has highlighted a bit of a usability issue that we need to give some more thought to. We have just sent this work off for external usability review so I'll make sure we discuss this if it doesn't come up in their findings.

Simon

Thanks Helen - I should have mentioned that all the hard work of developing this module has been done by Yuliya, so thanks should be directed to her!

Simon

Oh also we have enabled debugging on the test site so please let us know if you come across any errors while testing.

Simon

I'm pleased to report that Open Badges for Moodle is now in alpha and ready for initial testing!

The code is available on github here:

https://github.com/totara/openbadges

You can install your own site, or you can try out our test site here:

http://openbadgestotara.elearning.catalyst.net.nz/

We've disabled the external backpack connections and admin access on the test site but you can play around as a teacher (to create badges) or a student (to earn them).

Here are the login credentials:

username: teacher
password: teacher

username: student
password student

Some caveats:

1. Please don't use this code on a production yet. We are still fixing bugs and may need to make some breaking changes which will prevent you upgrading to a stable release.

2. This first release provides a basic (non-javascript) UI which we need for accessibility. We are planning on adding some more interactivity but wanted to get the basics working first. So please understand if you find some areas of the UI a little slow to use (particularly setting up criteria).

3. We haven't yet finished the full set of unit tests. We are working on that now.

4. We are also working on user documentation. For now, the specs give a reasonable description of the functionality:
http://docs.moodle.org/dev/openbadges
https://github.com/totara/openbadges-docs

5. We will be updating the github repository regularly and in order to keep the code organised and up to date with master we'll be rebasing and pushing forced updates so if you clone the repository you'll probably need to do hard reset when you want to update your local repository (you won't be able to just do a pull).

Aside from those issues, we would welcome any feedback, bug reports, etc. Once we've got the last few issues resolved we'll be pushing the code for integration review so if you'd like to see this in Moodle I'd encourage you to vote on the bug in the tracker:

https://tracker.moodle.org/browse/MDL-35073

Thanks,

Simon

I was looking at the Security settings and noticed this in the description of the setting "only http cookies":

Enables new PHP 5.2.0 feature - browsers are instructed to send cookie with real http requests only, cookies should not be accessible by scripting languages. This is not supported in all browsers and it may not be fully compatible with current code. It helps to prevent some types of XSS attacks.

Obviously that comment is quite old, and now that Moodle requires PHP > 5.2 and all modern browsers support it I wonder if it would make sense to turn it on by default?

What I'm not sure about is the line "it may not be fully compatible with current code". Does anyone know of any code that uses JS to access the session cookie intentionally?

Simon