Feature request: switch teacher UI to "no edit" mode

[piehei]

I suggest a new toggle in the teacher menu in course configuration that lets a course instance to be turned into a "no edits through UI" mode. In this mode all the edit buttons for rounds, deadlines, exercises, static material etc. would be disabled and all the course configuration knobs that may be updated through mooc-grader's aplus.json would only be updated through the "Import and override content configuration from URL" button.

Basically a new mode in addition to the current one:

• all stuff comes from aplus.json, teacher UI has disabled buttons etc.
• UI stays as is (currently implemented UI)

Background: all teachers and TAs have at some point made a little change through the teacher UI only to discover later that it was overridden by aplus.json and/or that it did not propagate "back to" aplus.json (to the course repository). Usually you learn from one mistake. However, one course can have many teachers and TAs that have no visibility into the underlying course repository and are not too familiar with the system which can lead to a growing number of errors. Thus, the no edit mode where UI disables edit buttons/edit forms would be very usable.

This would of course make the UI more obvious in every possible way.

One possible implementation would be something like a boolean in the course instance model and changes to the templates. I think that it would be reasonable not to make any POST checking and view specific changes – the implementation could be done on the front end and everyone could trust the teachers not to fire up DevTools, change the HTML, and fire up form POSTs to the backend.

What do you think?

This would be a perfect addition to the ongoing changes for configuration of course front page through aplus.json etc. When those changes ship, this chould be added too.

:)

[raphendyr]

Course edit page is deprecated and will be removed once all the functionality is moved to external configuration. Currently, we are migrating aplus.json generation from mooc-grader to roman plugin and thus finally to godfather. Once that is done, well make sure everything is doable via configuration file.

If you wish to implement this, then all the fields that come from aplus.json should be disabled when there is configuration url.

[ttsirkia]

Removing course edit page kind of enforces of using rst-tools etc. Some simple courses could be still configured via UI so could it be just made invisible or contain just the repo URL if the configuration is loaded from external file?

[oseppala]

I don't see the benefits of disabling the UI. There have been numerous times when i have had to put an exercise/chapter into maintenance mode using a device with no access to Git or the compilation environment. Its a critical feature for me.

The repository also should not be a place where we store such temporary changes as commits.

Otto

Lähetetty iPhonesta

Teemu Sirkiä notifications@github.com kirjoitti 15.8.2018 kello 0.09:

Removing course edit page kind of enforces of using rst-tools etc. Some simple courses could be still configured via UI so could it be just made invisible or contain just the repo URL if the configuration is loaded from external file?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[raphendyr]

Removing course edit page enforces of using Godfather as course management interface, what it's supposed to be. And there we can implement temporary changes (and relevant UI notifications for those) in addition to forms that make changes to git, so they we can have history and only single point for changes.

[ihantola]

As far as I understood, the proposed change was to add an option to disable the UI in courses where this might be needed. Thus, I don't share Otto's consern.

For other architectural changes in the future, I share Teemu's point of view. Forcing everyone to use the rst pipeline is not a good idea. Graders architecture should be as independent from a-plus as possible.

On Wed, Aug 15, 2018, 9:02 AM oseppala notifications@github.com wrote:

I don't see the benefits of disabling the UI. There have been numerous times when i have had to put an exercise/chapter into maintenance mode using a device with no access to Git or the compilation environment. Its a critical feature for me.

The repository also should not be a place where we store such temporary changes as commits.

Otto

Lähetetty iPhonesta

Teemu Sirkiä notifications@github.com kirjoitti 15.8.2018 kello 0.09:

Removing course edit page kind of enforces of using rst-tools etc. Some simple courses could be still configured via UI so could it be just made invisible or contain just the repo URL if the configuration is loaded from external file?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Aalto-LeTech/a-plus/issues/360#issuecomment-413102254, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJnEoVtKeh5OKYDx1hePOgF62qSlTXzks5uQ7lfgaJpZM4V76to .

[raphendyr]

Yes. Godfather is part of A+ core and thus we can remove dependency to mooc-grader. Design is to move complex logic that works well with Django to separate service, so A+ can then be implemented as simple proxy for the content with any fast and trivial language or framework.

[piehei]

Petri, good job! :-)

Others: I suggested a new mode for the teacher UI that could be enabled if so decided by the course personnel in a course-by-course basis. I did NOT suggest to change or remove any current functionality nor make anything new enabled by default.

Otto, I've done the same many times.

Please read the OP (or OI??) again dudes! There's even a clear user scenario that could be avoided by this (our head of department did this mistake last week).

I try to be clearer in the future.

[raphendyr]

My only point is that the required change doesn't seem too trivial and seems possibly a wasted work effort as the code will be removed sooner than later.

In other words, I would personally allocate the work effort to different tasks, but if this feature seems important, then feel free to implement it.

[piehei]

Roger that @raphendyr!

I'll look into it if I have some time.

[annirytkonen]

this idea has been suggested 4 years ago and has not proceeded since. Thank you for the discussion with versatile perspectives. I'll close the issue for now; it can be reopened if someone wants to return to the topic.