rusticisoftware/tincanstatementviewer

A statement viewing page for the Tin Can API.

###Overview

This repo contains a statement viewing page for Tin Can API statement streams.

• Copy the file config.js.template to config.js and set Config.endpoint to the LRS endpoint, including a trailing slash (ex: https://cloud.scorm.com/tc/public/)
• Set the endpoint credentials in Config.authUser and Config.authPassword as provided by the LRS
• Load: index.html in a browser

###Contact: [email protected]
http://tincanapi.com

tincanstatementviewer's Issues

Bug in resources/scripts/TinCanViewer.js - missing underscore

Line 573:

    catch (error){
        TCDriver_Log("Error occurred while trying to display statement with id " + stmt.id + ": " + error.message);
    }

Must be (note underscore) :
catch (error){
_TCDriver_Log("Error occurred while trying to display statement with id " + stmt.id + ": " + error.message);
}

Plamen

Statement viewer should support filtering actors identified by account.

I'm planning to address this.

"incorrectly failed" in activity stream sounds weird.

If a statement has:

1. The verb "failed"
2. An activity type of "cmi.interaction"
3. a result success of "false"

The activity stream will then display as in the screenshot attached. You get a similar thing with "successfully passed"

IMHO the adverbs "correctly" and "incorrectly" should only appear if the verb is http://adlnet.gov/expapi/verbs/answered.

There is a counter argument that statement viewer is for more technical people who may care more about the information than the grammar and that the viewer should continue to behave as it does.

Filtering 0.95 + 0.9 Results in Duplicate Display of 0.95 Statements in IE8

If I use Statement Viewer against an LRS with 0.9, 0.95, and 1.0.0 statements, the 1.0.0, 0.95 + 0.9 combined, and 0.95 filters work fine on initial use. But filtering on 0.9 shows me my 0.95 statements, and then returning to the 0.95 + 0.9 filter shows me a double set of my 0.95 statements.

I was unable to reproduce this in Firefox, so it might be an IE-only behavior.

'More' URL is parsed incorrectly

The /statements endpoint returns "more" with a value of:

http://localhost:3000/xAPI/statements?limit=25&related_activities=false&related_agents...

And the StatementViewer tries to load the following:

http://localhost:3000/http://localhost:3000/xAPI/statements?limit=25&related_activities...

Add enter/return key handling on filter inputs

Implement Cache-busting for IE

I can reproducibly create a scenario where POSTing statements (e.g., voiding) from outside an LRS implementing statement viewer seems to be ignored by IE* caching the Ajax request. Would be nice to have some cache-busting.