The real-time activity screen shows the online status of participants. This is currently based upon whether the user has a fulfilment or not and does not reflect whether the user is currently logging an ongoing fulfilment. As such, when the user finishes a schedule early they are shown as online when, in fact, they have finished.

In the log Actions page it is not obvious that a pledged Schedule is upcoming until the user clicks the Action now button. The message should be shown on the main page.

This can be achieved by setting the Secure flag and the HttpOnly flag.

The following error occurred after several minutes of the webpage sending successful alive message: XMLHttpRequest: Network Error 0x2ee7

When creating a new Schedule, clicking the 'New' button gives a default start time of now. This means that, when this is unchanged, the 'Schedules must be in the future' error message is always shown as the start time is always in the past.

A fix would be to set the start time in the future, on the nearest 5 minute boundary.

This should be validated against on the client-side and the server-side.

A parametric statistical method is needed and ANOVA is the most oft-used.

Validation should be performed on data models.

Admin forms should have client-side validation, where possible, and should provided helpful messages to the user.

The completion status of pledged participants should be displayed on the view Schedule page for schedules that are currently active.

When a group is deleted the reference should also be deleted from the User.groups field.

It seems that this is incorrect.

If the user has multiple tabs/windows open on the real-time Activity page then, upon cancelling or finishing one, the other windows will attempt to continue. If the activity has been cancelled then the user will be presented with an error; if the activity has been finished then a new one will begin. The desired behaviour is that the user is informed of this and that subsequent tabs/windows navigate to the Activity overview page upon receiving a cancelled or finished message.

This has a message blocking them from viewing activity but better would be to redirect them or give them a 403.

A nonparametric statistical method is needed.

The current view Schedule page only says completed or did not attend. It would be more helpful to say fulfilled, partially fulfilled or did not fulfil.

This would encourage users to log activities for them. An additional button for doing so could also be displayed.

The project has been superseeded by https://github.com/js-cookie/js-cookie

The displayed statistics should be extended to include:

1. Number of Fulfilments
2. Number of Schedules
3. Time pledged

Additionally, it would be good to include:

1. Number of pledges completed
2. Number of pledges partially completed
3. Number of pledges missed

This should be validated against on the client-side and the server-side.

Some users are reporting experiencing a redirect loop upon signing in. Clearing the browser cache seems to fix this.The cause is unknown at the moment.

This is currently enabled for the front-end UI but disabled in the back-end, causing an error to be returned from the API.

This is due to old code left in for pagination.

Dates are currently displayed in an input, more appropriate would be a picker of some description.

This is critical as users without a group are used for isolated studies.

Users with administrator privileges should be able to do this.

The following is shown You fulfilled your pledges to attend.

This is implied and should be omitted from the list.

How to reproduce: visit http://localhost:3000/meditation/log?date=27-03-2016&time=12-22&enddate=27-03-2016&endtime=12-25

Expected result: start time to be set to 12:22 and end time to be set to 12:25

Actual result: start time is set to 13:22 and end time is set to 13:25.

Image:

This could be to do with DST?

When displaying a deleted schedule a message should be shown to the user. Deleted Schedules should not be editable nor should a user be able to pledge to it.

When a schedule is removed, any pledges to participate should also be removed.

The app requires user authentication. This should restrict access to certain pages and modify data returned from API endpoints. Any hashing should take place client-side.