On commit, MatchError is raised

ning:~/github/cadet $ git commit
Pre-commit running...
usage: git stash list [<options>]
   or: git stash show [<stash>]
   or: git stash drop [-q|--quiet] [<stash>]
   or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
   or: git stash branch <branchname> [<stash>]
   or: git stash [save [--patch] [-k|--[no-]keep-index] [-q|--quiet]
                       [-u|--include-untracked] [-a|--all] [<message>]]
   or: git stash clear
** (MatchError) no match of right hand side value: {"", 1}
    lib/mix/tasks/pre_commit.ex:18: Mix.Tasks.PreCommit.run/1
    (mix) lib/mix/task.ex:314: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:80: Mix.CLI.run_task/2
    (elixir) lib/code.ex:677: Code.require_file/2

(on asciinema)

• Did try reinstalling dependencies with mix deps.clean --all and mix deps.get
• Did compile the app (by means of phx.server) before commit
• Replicable by @remo5000

Summary

In frontend's #81, we agreed with Prof @martin-henz to move the material (previously 'materials') and news (previously 'announcments') content to public access.

On the sprint 2 review meeting (9th June), there was some discussion about outsourcing the management of material and news to NUS IVLE. Source academy's material will map to IVLE's files (workbin); and likewise news will map to IVLE announcements.

This means that we can let IVLE handle user uploads, file and post management. Course administrators on IVLE will also be able to upload a file or create an announcement once, and have it appear on both platforms.

Proposed Solution

However, for this to work well, we will need IVLE to either

1. Provide a dummy IVLE user account with its own API key, or
2. Provide an API key that simply allows access to the CS1101S module on IVLE, or
3. Make the CS1101S module on IVLE's announcements and files public

A dummy IVLE user account can be added as a student to the CS1101S module on IVLE. We can then access the IVLE announcements and files (workbin) through this dummy account. As long as the dummy account is in each semester's CS1101S module, we will not need to change anything from semester to semester.

An API key that directly provides access to the CS1101S module would make things much simpler, but I suspect that IVLE does not have the ability to generate such a key. Similarly, option 3 of making course announcements and files public is the simplest way out, but again IVLE may not have this capability.

To conclude, we should request for option 3 first, then 2, then 1.

Backend

Should option 3 be made possible for us, there would be no need for the backend code base to act.

For options 1 and 2, however, my opinion is that the frontend should not fetch IVLE data directly. Instead, the backend should periodically fetch and store the information from IVLE, and then provide it to the frontend via API call. This ensures that neither the API key nor the user authentication token (for option 1) will be exposed to the end-user.

Although so far according to discussion with front-end, they don't need this yet.

Use latest version of React and BlueprintJS

Proposal

When querying questions, I believe that a library will only be present if the question is of type programming. Can it be returned for both types of questions (i.e be an invariant like content)?

Rationale

The MCQ questions will still need a REPL for students to try out code, so we want the REPL to run code in a specific library. Since both Programming and MCQ questions will have a library, we can define the library in the question instead.

Update the documentation and remove all npm stanzas such as package lock

Try Lambda first, if it doesn't work use ECS

We should abandon the current custom Webpack configuration and simply use react-script-ts.

• GradingController #67
• AnswerController #65

According to https://gist.github.com/remo5000/cd6923c6fa004442bbc7c633718966fc, there is a difference between the library structure in cadet and cadet-frontend.

Since you are the ones using the library, I'll change the version stored in the backend to your version. Sounds good? @ningyuansg @remo5000

• #66 AssessmentsController

According to @evansb's comments on #81

Since we have 2 full time frontend engineers and 2 part time + 1 full time backend engineers, I think it makes more sense to make the frontend a single page application, and having the backend engineers write a RESTful API instead of server rendered.

We will disucss this in the first sprint meeting.

@sreycodes:

We need some way to decide which story act in the game to show the user. These correspond to the files in the repository cs1101s/cs1101s at ./stories. At frontend, the logic we will be implementing is:

1. Are all assessments attempted? Then spawn the open-world spaceship
2. If not, spawn the story act of the unattempted assessment with the lowest assessment id.

For your reference, the corresponding files in source-academy/source-academy2 of this functionality:

game.html.eex

<%= link "Attempt",
      id: "attempt",
      style: "display:none",
      method: "put",
      to: assessment_path(@conn, :attempt, @assessment_id) %>
<div id="game-display"
     class="sa-game"
     data-story="<%= @story_override || @story %>"
     data-attempted-all="<%= @attempted_all %>"
     data-username="<%= @username %>">
</div>

page_controller.ex

  def game(conn, params) do
    user = conn.assigns.current_user
    student = conn.assigns.current_student
    assessment = Assessments.prepare_game(student)
    story_override =
      if Accounts.staff?(user) do
        Map.get(params, "s") || nil
      else
        nil
      end
    if assessment == nil do
      render conn, "game.html",
        assessment_id: -1,
        story: "spaceship",
        username: student.user.first_name,
        story_override: story_override,
        attempted_all: true
    else
      render conn, "game.html",
        assessment_id: assessment.id,
        story: Assessments.story_name(assessment),
        username: student.user.first_name,
        story_override: story_override,
        attempted_all: false
    end
  end

assessments.ex

  def prepare_game(student) do
    # Get all non-attempted assessment
    assessments = Repo.all(
      from a in Assessment,
        left_join: s in Submission,
          on: a.id == s.assessment_id and s.student_id == ^student.id,
        where: is_nil(s.student_id),
        select: a
    )
    # Filter those can be attempted, min by order, mission first
    assessments =
      assessments
      |> Enum.filter(&(&1.type != :path && can_attempt?(&1, student.user)))
    if Enum.empty?(assessments) do
      nil
    else
      [hd | _ ] = Enum.sort_by(assessments,
        &story_name_pair/1,
        &compare_story_name_pair/2)
      hd
    end
  end

  def story_name_pair(assessment) do
    {assessment.type, assessment.name}
  end

  def compare_story_name_pair({t1, n1}, {t2, n2}) do
    cond do
      t1 == t2 -> n1 <= n2
      t1 == :mission -> true
      t1 == :sidequest && t2 == :mission -> false
      t1 == :contest && t2 == :mission -> false
      t1 == :contest && t2 == :sidequest -> false
      true -> false
    end
  end

  def story_name(assessment) do
    type = Atom.to_string(assessment.type)
    String.downcase(type) <> "-" <> assessment.name
  end

Where models have foreign keys that cannot be null, the tables should have appropriate constraints and
changesets should also validate this with Ecto.Changeset.foreign_key_constraint/3.

See here for difference with Ecto.Changeset.assoc_constraint/3.

Todo:

• Update changesets
• Add migrations

Refer to https://github.com/thoughtbot/ex_machina#splitting-factories-into-separate-files

• Use modular approach

• Create entry point for staging that instantiates the terraform module

Here be sprint goals. Include the PR number in parantheses.

Sprint 1

APIfy everything!

• Transform current repo into REST API, JSON (#32, #33)
  • In-Progress
  • Under Review
  • Done
• Finish up Assessment context (#34, #35)
  • In-Progress
  • Under Review
  • Done
• Use swagger to do API documentation (#31)
  • In-Progress
  • Under Review
  • Done

Sprint 2

Review process: review each other before asking for Evan's review.
Focus on the public facing stuffs, finish up basic flow w.r.t. missions

• Submission by student
  • In-Progress
  • Under Review
  • Done
• Grading by tutor
  • In-Progress
  • Under Review
  • Done
• IVLE login stuffs (processing IVLE token)
  • In-Progress
  • Under Review
  • Done

Low priority

• Pulling data from git to create missions
  • In-Progress
  • Under Review
  • Done

The register method currently hardcodes each new user as a :student.

Right now all of them have no tests. Follow https://github.com/source-academy/cadet/tree/master/test/cadet/course

The current default landing page is News. If the
user clicks on Source Academy, they are brought
to the 'anonymous' (no associated navigation
button) Game component.

If this user is not logged in, they will receive
a pop-up LoginDialog. However, the Game
component will still render. This possesses a
problem with regards to performance, as well as
data (there is no data in state.session to
indicate username, story...)

Furthermore, we expect similar problems if a user
who is not logged in visits directly, via URL, any
page under Academy.

As a solution, we should move the login into its
separate component, 401. When the react router
receives a user request for /academy/*, the
router checks if the user is logged in. If the
user is logged in, the user is routed as per
usual. If not, the user is redirected to the 401
page instead, by-passing the render of Academy
components. When a user successfully logs in via
the 401 page, we call history to return to the
Academy component the user was trying to access.
If the history is empty, default to /academy/game.

In today's meeting, the SoC systems engineer raised concerns over the security of the long-lived (52 weeks) refresh token. He recommends a validity period more similar to IVLE (8 hours).

From today's meeting, there needs to be one more role value for the graduate student. Overall, there will be 4 roles, corresponding to:

1. Site administrators, which corresponds to the module's two professors. Site administrators should be able to access all assessments
2. Graduate students, who are responsible for manual marking of assessments. Graduate students should be able to access only assessments belonging to students assigned to them
3. Avengers/TAs, who will be able to access only assessments belonging to their studio group
4. Students

Implementation-wise, it is possible to give graduate students an identical 'role' value as avengers/TAs. The difference being only the students they are assigned---graduate students are assigned (associated) all the students they are responsible for grading, and avengers/TAs are assigned (associated) the students in their studio group.

More importantly, we need to take note that the information about these groupings will come from IVLE groups. Therefore, a process of parsing IVLE 'group' information into the backend database, as well as a way to update these relationships (as in, to update per fixed amount of time, or on student login, or on graduate student/avenger login) should be implemented.