Suggestion to deprecate the little used `sysadmin` management dashboard

#1

There’s a little known feature in Open edX called the sysadmin dashboard.

While nice to have, it’s sometimes broken especially when deleting a course. I spent some time to fix it, and I did fix an issue with deleting the course only to realize that most of the community doesn’t use it.

This feature can be enabled with the ENABLE_SYSADMIN_DASHBOARD feature flag in the LMS and would be available on the http://your_lms_url/sysadmin to delete courses and register new users among other “admin” features.

Here’s a couple of reasons on why we should remove this functionality:

  • It’s not being used by most of the community (speculative guess) but still requires regular maintenance.
  • It lives in the LMS although it has functionality that belongs to Studio, like course deletion. This leads to bugs that can only be solved via import tricks or serious refactoring.
  • This is a perfect example of what should be a pluggable app because we’ve had a plugin system since Hawthorn.
  • If removal is not an option, then let’s consider splitting it into two apps, and LMS sysadmin and a Studio sysadmin.

What do you think?

#2

Hey Omar,

Thank you for your proactive suggestion and helping us toward making our core more maintainable and better factored. I agree with your recommendation of deprecating and removing this feature from the core platform, if most of the community is not using it (and hence not a core feature). I agree that the few members who may be using it can do so as a Pluggable app.

Do you have access to create a DEPR ticket on our JIRA dashboard? https://openedx.atlassian.net/browse/DEPR

We can follow the DEPR process to communicate and get input on removing this feature:
https://open-edx-proposals.readthedocs.io/en/latest/oep-0021-proc-deprecation.html

#3

@omar: Agreed on all points. I’ll add another two:

  • It’s one of only two parts of the edx-platform codebase that has MongoDB as a direct dependency (and I’d love to eventually drop MongoDB to help simplify the stack).
  • It doesn’t scale to a large number of courses, as part of it does a full iteration of all courses in the modulestore.

It was basically an escape hatch of needed functionality built in a much earlier time. I know that there are some early adopter power users that use this feature on their instances, like MIT and Stanford, but we would absolutely advocate that people implement it as a pluggable app if it were created today. I discussed this with @pdpinch on edx/edx-platform:20493, but we never reached a conclusion.

#4

MIT is a regular user – of the delete feature, and the ability to import courses via git (among other things, it’s the only way to share logging with course authors about course import errors).

I think the last time we (MIT) submitted a PR for the sysadmin panel, @dave extracted a promise from me that we would convert it to a pluggable app in exchange for his thumb on the review.

One of my follow-ups that I haven’t found the time to do is to look to see if the needed APIs are available to make it pluggable.

1 Like
#5

Django App Plugins can cheat there, as they’re in-proc and can basically import anything they need in edx-platform (though in practice, you’ll want to be careful about your dependencies). You should check out @jill’s portion of the pluggability presentation from the last conference for a quick primer if you didn’t get to catch it live.

#6

We rarely used it but it has been useful from time to time. As long as there is a replacement available to the Open edX community, it can be deprecated but not if something is not made available before.

1 Like
#7

@sambapete I think it would be a great repository to add to https://github.com/openedx. It would start as a copy of the existing app but modified to configure itself as a plugin.

1 Like
#8

It’s possible to bypass having a proper API using direct calls in the core, but that’s not a maintenable way to build plugins. If we start moving pieces from the core to plugins, imho we should make sure there is a proper way to contribute the proper APIs to support that plugin, before considering it an option. Otherwise this makes it really hard for people who take on building and supporting such an plugin to do so, since the ground will keep moving below them - and since there is no way for people committing in the core to know that a change breaks it, it makes maintenance harder, overall, than the current situation.

1 Like