🪲Explore page: "retract program" button visible to any teacher

[rix0rrr]

What's the problem?

If a teacher browses the "explore" page and clicks a program, a "retract program" button appears. It might not be just for teachers, it is at least for teachers.

This button even seems to work, as in: even if the program is owned by an arbitrary user, I can click it to un-submit it.

What's the solution?

This button should never appear on this page, probably not even if you are the user that wrote this program.

The problem might be caused by reuse of HTML components between the regular "edit" page, the "my saved programs" page, and the "view program" page.

Next steps

Someone should investigate how this has happened to begin with. Why did this button appear on this page? Is there re-use of HTML components that leads to changes on one page to having an effect on another page?

No fixing needs to happen yet, just this question needs to be answered.

[boryanagoncharenko]

The fact that the Unsubmit program button appears on the Explore page is an explicit feature request done in #4634. A teacher expressed the need to unsubmit programs of students when changes to the programs have to be made. In fact, the teacher requested a mechanism to let students know that their program needs to be corrected, which is a mechanism we still don't have and perhaps is a good idea to keep in mind given the teacher-happiness improvements we aim at.

Based on the PR, it is not clear whether it was overlooked or it was intended to give all teachers the superpower to unsubmit the programs of all students (as opposed to only to students they currently teach). The PR has a how to test section which includes only the positive testing scenario. Permissions were not mentioned in the course of the PR review.

If a student can be enrolled in a single class, then a teacher should be able to unsubmit only the programs of the students they are currently teaching. Unsubmitting programs of another teacher's students will negatively impact that other "classroom".

Let me know if you would like me to create further issues based on the investigation above.

[rix0rrr]

Thanks for looking into it!

Based on the PR, it is not clear whether it was overlooked or it was intended to give all teachers the superpower to unsubmit the programs of all students (as opposed to only to students they currently teach).

Common sense says that this should not be allowed to happen, so I would expect if it was intentional that there would have been an explicit request for it. My suspicion is that it was overlooked.

In fact, the teacher requested a mechanism to let students know that their program needs to be corrected, which is a mechanism we still don't have and perhaps is a good idea to keep in mind given the teacher-happiness improvements we aim at.

Good call-out! The submitting and freezing mechanism needs another overhaul anyway. @Felienne recently came up with a grading mechanism that seems more general-purpose: being able to look at all students' programs, and "mark them off" if the program is sufficient. The program can be "submitted" or "not submitted"; in that workflow, "submitted" functions more like a guarantee that the program cannot be (accidentally) edited anymore by the student, so the "last updated" timestamp can count as the "hand in" date. Adding a note and putting the program into a state of "work needed" seems like an easy extension of this workflow.

I will take that into account when I'm thinking about grading.

For now, I think for now we can convert this issue into: a teacher should only be allowed to unsubmit programs of students that they teach. Also, the button and caption take up a huge amount of space. Can we put it somewhere else and make it smaller so it's not so distracting?