Fire events from authoring_api so that downstream effects can be handled in edx-platform

[kdmccormick]

Background

In other words: it should be safe to call authoring_api directly, rather than be forced to go through xblock_api and libraries_api, and expect that the authoring_api's events will be sufficient for edx-platform to manage any downstream effects.

The specific thing that brought this to our attention was libraries indexing. If you call authoring_api directly, then you are allowed to edit library content within Learning Core, but it will not trigger the necessary reindexing within edx-platform. So, we have been forced to create wrapper APIs in edx-platform within the content_libraries_api.
It would be better if the content_libraries_api was only needed for Libraries-specific things (creating a library, renaming library) and that all content operations could safely be done via the authoring_api, triggering events which the content_libraries app would catch and use as a signal to begin reindexing the affected content.

AC

• Define openedx-events for component and container authoring
  • Delete
  • Publish
  • Create/Edit (batched by DraftChangeLog)
  • Collection operations
• Fire those events from the authoring_api function calls
• Consume the events in the content_libraries app and reindex content as appropriate
• Consume and react to any other events as appropriate
• Take into account existing events that need to be re-fired based on these new Learning Core events. Hypotheticals:
  • xblock_created
  • xblock_updated
  • library_block_updated
  • library_block_published ??
  • etc...
    DEPR the ones that are non-batch.
    Where possible, populate event data from LC rather than by invoking the XBlock runtime.
• As appropriate, move functions from libraries_api down into xblock_api and authoring_api, and/or remove unnecessary libraries_api wrapper functions. Update existing references.

Notes/questions

• For content edit events, each one should be fired upon commit of the entire DraftChangeLog, not each DraftChangeLogEntry. This way, we get one event per batched edit of entities, rather than one event per entity.

• Other than reindexing, are there any other instances of handling these events that we think we'll need for Libraries?

• When we have Courses in Learning Core, the Publish event will be used for many many things. Currently, we catch COURSE_PUBLISHED and have a huge handler that does a lot of things (proctored exam registration, due dates, block transformers, outline generation). As we move to LC, we'll want to move to doing more-scoped recomputation based on these events.

  • Need example of "more scoped event handling"

[kdmccormick]

FYI @bradenmacdonald -- as we discussed in Slack

[bradenmacdonald]

Thanks for writing this up @kdmccormick !