Suggestion to deprecate the little used `sysadmin` management dashboard

Development Architecture
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.

2 Likes
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.

2 Likes
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
9

I’m wondering if this is a useful place to think about what Python APIs would be needed to make this component fully extractable as a pluggable thing. How could we find that out?

1 Like
10

@nedbat That would be great to find that out, yes - if we could have a good path to figure out the path in cases like this, that would make the switch to modules & APIs much faster. Currently we are blocked on core -> module conversions in a number of places because there isn’t a way to discuss/decide that.

@nimisha Do you think you could suggest something for this?

I’m also going to include a point about this in the agenda for the next Open edX Contributors Meetup.

11

@antoviaque Yes, I can help with this. We can determine a few guiding principles for a Python-API framework (preferably in the form of an edx-platform ADR) and work with a developer to implement the beginning stages - starting with unblocking this extraction.

Thanks for adding to the agenda.

1 Like
12

@pdpinch We discussed this with @nimisha and @nedbat during last week’s contributors meetup, and there was a general agreement that this would be a good case to establish the Python APIs that would be needed to make this pluggable. There would likely be many of the requirements here that would be reusable for many other plugins, so it’s a good stepping stone. It’s also something that is already on the platform currently, so removing it would help to make the case for this work being useful, and doing it once would help to establish a process we could then replicate to allow to support other plugins in the future.

What we weren’t sure about was your availability and timeline on this. Would you be able to work on this now? This is an important step that we need to take to be able to properly support plugins in general - not just the sysadmin dashboard. No pressure :slight_smile: but until we do this, a lot of the work to move towards plugins will remain blocked.

13

Thanks for asking @antoviaque, but I’m not sure I understand the scope of the work in question yet. At a high-level, I suppose it’s something like:

  1. Identify APIs that the sysadmin panel would require
  2. Design the APIs and get community buy-in
  3. Write the APIs and get them merged
  4. Write a new sysadmin panel (as a pluggable django app, right?)
  5. Remove the existing code

I think MIT Open Learning has to be involved with #1 and #4. Are you also asking me what our capacity is for the rest as well?

14

@pdpinch That’s a good question, I’m not sure what was your understanding with @dave on this :slight_smile: I’m interested in it from the point of view of allowing API development/support improve - so maybe we/OpenCraft could help with contributing some of the APIs, and you contribute some too?

@nimisha @nedbat How do you think of helping this effort? Would you want to do some of the design and implementation yourself?

15

I’ve opened a draft ADR for guiding this discussion, at https://github.com/edx/edx-platform/pull/24048

To replace the functionality of the sysadmin dashboard, I believe we need just 4 APIs (available to a pluggable django app):

  1. Create a cms user account
  2. Import a course from git
  3. Delete a course
  4. Staffing and Enrollment statistics

It would also be really helpful to have a way to plug into the Instructor dashboard UI, so that some features like import from git and import error logging would be available to course instructors where they might look for it.

16

Great news @pdpinch! I have no further comments except for the instructor dashboard.

It would also be really helpful to have a way to plug into the Instructor dashboard UI, so that some features like import from git and import error logging would be available to course instructors where they might look for it.

So currently the instructor dashboard is pretty much well hard-coded with no pluggability.
I think it would be great if we can make it pluggable but having checked it myself earlier I don’t think it’s going to be easy.

So I’m thinking that of a lightweight list of links to be plugged into the dasbhoard. Something as simple as:

INSTRUCTOR_DASHBOARD_LINKS = [
  [ugettext_lazy('Do something with git'), '/custom_plugin/course/{course_id}/git'],
  [ugettext_lazy('Go to Figures'), '/figures/course/{course_id}/metrics'],
]

It could also become part of the Open edX plugin system https://github.com/edx/edx-platform/blob/master/openedx/core/lib/plugins.py, what do you think?

I think it would be fairly reasonable and pretty useful to have in the current ADR. What do you think?

17

FYI for those who weren’t at the Open edX Contributors Meetup last Thursday, @Felipe, @nimisha and @pdpinch discussed reusing the APIs from eduNext’s set of APIs - which are the ones from this repo I think @Felipe, right?

The next step is for @pdpinch and @Felipe to figure out whether the APIs there provides the required functionality, and to discuss with @nimisha and @nedbat how to make these APIs officialy part of Open edX.

Edit: See also https://trello.com/c/vkXNSu2X/23-apis-sysadmin-dashboard-conversion-write-adr

18

So those links would be rendered as tabs in the instructor dashboard? I think that would be helpful.

1 Like
19

@Felipe sorry I’m a little lost looking through eduNEXT/eox-core . Are there any existing APIs (or UIs) that would address one or more of these features?

20

Hey @pdpinch,

From those 4 requirements, I only see one API currently in our plugin. That would be the one for the users.

We are having an internal discussion these days to perhaps split this APIs into a separate plugin and make that a requirement for all the plugins in the eox- family.