Store the course assignments in a dedicated subgroup rather than the student's namespace
Context
Currently, the student submission for a course assignment is stored in the student's namespace. This has two caveats dues to GitLab limitations:
- User namespaces can't hold subgroups, preventing to group the student's submissions by, e.g., courses, sessions, etc.
- If the namespace contains a '.' (which is typical for
first.last
user id's, then user's gitlab pages (as e.g. generated by autograding with travo+nbgrader) can't be served properly with https, forcing the reader to accept an certificate exception.
Proposal
- Create a dedicated group to hold the student's submissions, named
after the user's login, replacing
.
by_
, and appending some suffix. E.g.nicolas_thiery_submissions
. Ornicolas_thiery_travo
. - Store a student submission at the path
<student's group>/<course>/<session>/<assignment>
instead of the current flat path<student's namespace>/<course>-<session>-<assignment>
. Variants:- for a course without sessions:
<student's group>/<course>/<assignment>
- for a course with several stages (e.g.
Methnum/L1
,Methnum/L2
:<student's group>/<course>/<stage>/<assignment>
)
- for a course without sessions:
Implementation
It should be sufficient to:
- update
CourseAssignment.personal_repo_path
- update
Project.ensure_fork
to create intermediate subgroups as needed -
maybe update the instructor's access policy, so that instructors for a given session have access toAfter testing with @jneveu, this is not needed. If you have access to a project within a private group that you are not member of, then you can still browse that group and see all projects there that you have access to.<student's group>/<course>/<session>/
and instructor's of the course have access to ``<student's group>//` (see below). This is somewhat more complicated than the current policy "devs of the assignments have access to the submission" which is not specific to courses.
Caveats
-
This is an incompatible change for a currently running course. And it may have unforeseen inconvenients in practice. Thereby this feature would be made optional, and turned off by default for now.
group_submissions=False
Later, if it turns out to be convenient, it could be turned on by default after an appropriate deprecation period for not explicitly setting its value.
-
Two users with respective identifiers
a.b_c
and anothera_b.c
would lead to a conflict in the produced student group paths. -
For an instructor to browse the list of submissions of a student for a given session, s.he needs access not only to the submission themselves, but to the group holding them.
Note: currently, if a user set's her namespace to private, then the instructor already can't browse her list of submissions.
Call for comments
-
Thoughts anyone?
-
Is this adding complexity?
-
Any preference for the student's group naming scheme? In particular the suffix? One option might be to make it customizable via a `group_submissions_path='_travo'.
cc: @jneveu, @privat, @viviane.pons, @Blondin_Al