yeldirium / st3k101 Goto Github PK

When scrolling down through a dimension, it is not obvious that the next tab should be clicked to continue answering the survey. To make navigating the survey easier, there should be a "next" button at the bottom of a dimension, which will advance the selected dimension to the next dimension that is not completed yet.

At the moment, multiple instances of a template questionnaire by the same owner can't be differentiated by their activity ID. When issue #112 is resolved, this will apply to all copies of a template.
To differentiate between multiple instances, another context activity should by added to xAPI statements, under the other category. The activity should have an activity ID unique to the specific instance of the questionnaire.

This needs to be enabled in the api with maybe an additional endpoint for explicit switching of elements' places.

Current frontend plan: Two buttons on elements. An arrow to the top, which switches the element with its predecessor and one to the bottom, which switches the element with its successor.

Instead, the owner should be placed in the context, as the instructor.

The current error handling assumes that a connection can always be established.
All kinds of network related exceptions should trigger retries.

Needs to be investigated.

Some xAPI statement uses the DataSubject as XApiActor and then fails.

  File "./framework/xapi/XApiPublisher.py", line 44, in enqueue_deferred
    'statements': [s.as_json() for s in statements],
  File "./framework/xapi/XApiPublisher.py", line 44, in <listcomp>
    'statements': [s.as_json() for s in statements],
  File "./framework/xapi/XApiItem.py", line 22, in as_json
    return json.dumps(self.as_dict())
  File "./framework/xapi/XApiStatement.py", line 51, in as_dict
    "actor": self.get_actor().as_dict(),
AttributeError: 'DataSubject' object has no attribute 'as_dict'

This is confusing for users.

At the moment, the description describes the type of activity, but not the instance of the activity in the statement.

This is most likely due to marhsmallow returning errors instead of raising them again.

When a DataSubject enters an invalid email address, the backend does not return an error until it tries to access the email address, which at this point does not exist in the data anymore.
This error should be caught and communicated to the DataSubject.

It should instead display a meaningful error message to the user, possibly highlight the password input and focus it for ease of use.

Should improve build time a bit.

When I update the bundle, the frontend does not seem to change, even after Ctrl+Shift+R.

Currently we have an explicit list of all modals in the App component.

Thid is hard to maintain and clutters the app's entry point.

Possible solutions:

• lazily look for modal components on call
• eagerly load all modal files at startup

This seems to exclusively affect buttons.
Needs to be investigated.

Possibly by supplying a sql dump ans loading it into the database

Currently unknown errors get the same error message (although a different error type) as conflict errors.

Usually, all questions of a certain dimension use the same response range.
This may not always be the case, so at the moment, range labels are set on a per question basis.

To make the workflow easier in the frontend, there should be a way to update all range labels in a dimension at once.

At the moment, the backend is configured on build. This is obviously problematic, as the config can only be updated by attaching to the container and rewriting flask.cfg.

The modal then shows no results for some time while the loading spinner is in the background. This is potentially confusing.

Greenkeeper should be configured (including greenkeeper-lock).

This includes a ci update, since greenkeeper-lock has to update package-lock.json.

The link in the email send to the users after their submission is broken:

Hi there!
You've recently participated in the survey Coolness.
To confirm your submission, please follow the link below:

http://https://survey.edutec.guru/api/response/verify/659a4dfc9289a292d1a7ec2fc9baf18a
<

In the backend.env the domain is set as:
DOMAIN_NAME=https://survey.edutec.guru

When creating a new ConcreteQuestion as part of a ConcreteDimension that is a template,
the associated ShadowDimensions do not reflect the change.

Whether a survey is published or it accepts new submissions are semantically different things.

When a survey is not published, the API won't deliver it to the frontend, thus it, or any information about it cannot be displayed.

When a survey is published, but does not accept new submissions, it will be delivered by the API and the frontend may render information about it, yet there's no way to submit.

Use Cases

1. Embedding a survey before accepting submissions

A DataClient may choose to embed the survey before they intend to collect data on it. At the moment, a DataClient can't verify that the embedding was successful without also accepting submissions by anyone who has access to the course where the survey is embedded. Usually, course content is set up before the course starts, so the embedded survey should start out published, but only display some generic information about the survey alongside an information text, detailing that the survey can't be taken yet.

2. Concluding a survey

At the moment, when a DataClient decides not to accept new submission anymore, they have to retract the survey, which will break all existing links and embeddings, as the frontend can't gather any information about surveys that are not published.

Proposed changes

1. Add accepts_submissions flag to Questionnaire
2. Update *SurveyForSubmission components to recognize the new flag and only display a landing page
3. Update API to only accept submission, if the accept_submissions flag is set
4. Update the frontend to allow setting of this flag.

We want automatic test execution with ci and coverage and output processing.

I want to use jest.

Because of #53 , there's no concluded state for Questionnaire anymore.
The associated xAPI statement should either be removed or adapted to the new states.

Problem: Setting accepts_submissions to false is revertible, so clicking the toggle multiple times would issue multiple xAPI statements.

Dimensions should be re-orderable inside a Questionnaire. Same thing applies to Questions inside a Dimension.

Long term, survey items should be re-orderable via drag & drop in the frontend.
As a proof of concept, up and down arrows should be added in the frontend to swap the positions of two items.

From user feedback:

I had two groups of statements (called "dimensions" in this survey system), for each group there was an instruction (called "description" in the system). It would be nice to have a possibility to create an instruction/description for each individual group of statements/dimensions within the same questionnaire. Now it is only possible to create an instruction/description for the whole questionnaire.

From user feedback:

It would be very useful to have possibilities to create different kinds of questionnaires including open questions, multiple choice questions, or questions with "correct"/"incorrect"/"I do not know" answer options.

Because of the GDPR, there has to be a way to remove personal data of DataSubjects from the database. This should eventually be possible without the intervention of an Admin user, but would require some sort of authorization for DataSubjects and it's not obvious what mechanism should be used for this.

As a workaround, at least the Admin user should be able to remove personal data from the database on request. For this, I propose a searchable list view that is available to Admin users, which displays DataSubjects, but not their responses and allows for deletion of all DataSubject related data.

The changes will consist of an endpoint for querying DataSubjects, an endpoint for deleting all data related to a specific DataSubject and a frontend component presenting the query results as a list.

Reasons are obvious, an endpoint might return 201 when creating a resource for the received xAPI statement.

It should just use the browsers suggestion and not do anything else.

Unittests that do not require the built images should be run before building.

This is also necessary for greenkeeper to work, since it needs to update the lockfile, than run tests, then push the lockfile. This can't be done inside the image, thus tests need to be run outside of it.

Since redis is required by xapi-publisher, we should also switch the backend container over to redis, as this would remove the memcached container from the project.
Less dependencies => more happiness.

Currently the Questionnaire-endpoint does not include information about the activated challenges.
While that is intended for the e-mail white- and blacklist, the frontend needs to know, whether a password is required.

This blocks #13.

We want to use semver.

We currently have separate version files for the services in their respective folders and intend to keep them up to date conforming with semver.

However this makes it difficult to version the repository with tags.

We could either use service specific version tags (e.g frontend-2.0.1) or, we could split the repo as discussed a few times and version each repository.

The latter would include a rewrite of our ci system and an external docker-compose config.

If I add a Shadow* that references a Concrete* of the same parent, when trying to delete the Shadow again, the following edge case may occur:

If the parent is a template and there exist shadow copies of it, the backend will try to delete the Shadow* from the parent's shadow copies as well. Because copies of the parent include the Shadow* twice (once as a direct copy of the Concrete* and another as an indirect copy of the Shadow* we've just created), the delete query will mark them both for deletion and the query will fail.

The backend should either detect this edge case (potentially hard without distinguishing between direct and indirect shadow copies) or disallow adding the Shadow* in the first place, since there's no use case for it.

Config must be adapted asap.