Add our extensions to the Extension Directory

Discussions - Public
1

@team We need to add all OpenCraft extensions to the Extensions Directory displayed on the Open edX site. This is a great way to show off what we can do!

Please add any extensions you know of to this spreadsheet. You can use this Google Drive folder for any images you save. I will share the spreadsheet with the Open edX WordPress team when it’s ready.

Thank you!

:timer_clock: Ticket to log time

3 Likes
2

(Note: The below list has been updated as per the responses in this thread)

Which of the following extensions are still in working order?:

Thank you!

3

I can answer for a few of them.

  • The Drag and Drop XBlock is already bundled with the platform
  • XBlock poll and survey are also bundled with the platform
  • Group Project requires a heavily customised fork of edx-platform to work and as such it should be considered deprecated. It was used by one client using that fork and they don’t use it any more. It would require a lot of investment to make it work with the vanilla platform.
1 Like
4

Would this plugin count?

5

Adventure block is depr’d: Deprecation/Removal: Adventure XBlock - Deprecation - Open edX discussions

1 Like
6

This is the first I’ve seen of this-- and it’s something that Axim and the community has been eagerly wanting for an extended while. How close is this to being generally useful vs highly specific to this client?

7

@Ali Vector Drawing is deprecated, too, now I believe (ref).

1 Like
8

Almost everything in this extension is highly specific. There is a pattern than can be seen (e.g. there is a signal → handler → api request to custom endpoint) in this and a similar extension which is developed for another client that uses Salesforce. However, extracting it into a reusable code or an abstraction wouldn’t make sense in my opinion, especially since it also requires custom code on the Salesforce side.

I’ve seen this ticket on the roadmap before. My impression is that the scope is user management and enrollment:

Integrate with SalesForce, allowing enrollment and user management through its CRM capabilities.

The client that I work with uses bulk_enroll API endpoint to enroll learners. Users are created when they sign in for the first time using SSO. So they don’t need any custom integration, other then the edge case. The edge case right now looks like this:

  1. User is created in Salesforce with an email alice@example.com.
  2. Salesforce (using the custom integration that was written by the client’s salesforce team/person) sends requests to the bulk_enroll API which accepts a list of emails.
  3. User changes their email in Salesforce to bob@example.com, before ever logging into LMS.
  4. They log into the LMS, and the user record that is created receives bob@example.com as user’s email. Since the enrollment records were created with alice@example.com, the learner is not enrolled into any of the courses, unless we manually intervene.

The suggested work around was to create a new endpoint or modify/extend the existing one, so that it uses unique ids generated by Salesforce which would never change, to avoid this issue with the emails. If and when this customization is developed, it would probably be added to the same repo. If it is useful to other people, we can look into options of upstreaming it, or separating it into it’s own repo.

9

I would imagine that it doesn’t need to be in the extensions directory, then. But someone at Axim might be able to make use of the code as a reference/starting point. It still leaves the SalesForce side of the equation unsolved, but having the attachment points visible may give whoever ends up implementing it a hint.

Nevertheless, that’s more a comment for the ticket than it is a reason to put it in the directory.

10

Is there a way to make the specific behavior more useful to others - making the specific behavior more a specific configuration of a more broadly generic extension?

Cf what I was mentioning in Upstreaming, forks, plugins & themes about the use of plugins:

Also note that even in the case of a plugin, we should still contribute it to the project: post product proposals, ADR, and if there is interest for having it in the standard distribution, still get it included there. This is important, as more and more features will be developed as plugins - we should still do the effort of “upstreaming” those.

It is one of the 3 big no’s: “Making the change in a plugin that we don’t attempt to contribute to the project” - it might be in a plugin, but it still deserve the same attention as any code to upstream.

11

Based on everyone’s feedback, it looks like the extensions we can add to the Extensions Directory at the moment are:

I’ll go ahead and share the details of each block with EduNext (they’re the ones in charge of updating the directory). Thanks to everyone for their help, and please let me know if you think of any other extensions to add.

12

Hi, @Ali . I was surprised to read that we were going to send this information to EduNext-- they already have the information on the Kinescope XBlock, as I submitted it to them months ago-- they confirmed receipt, so I know they have it, and I have been bothering them for months about getting the directory updated. Sending a new spreadsheet will not fix this.

I’m now raising the issue further here, in the thread talking about the new marketplace where it can get more attention and hopefully be resolved.

2 Likes
13

@Fox Thanks for sharing that message in the Marketplace thread. Fingers crossed it leads to some useful feedback.

1 Like