Track user publish intent in PublishLog

[ormsbee]

Per this slack thread, I think we're going to want to extend the PublishLog model to include a nullable field that captures what it was that the user clicked "publish" on. This seems to be a requirement of the UX:

Right now, if there is a Subsection -> Unit -> Component setup where only the component has changed, the data in the PublishLog does not allow us to differentiate which level the user pressed "Publish" at. The PublishLog currently only tracks what was published, not what the user asked to be published. So if the Component was the only item with unpublished changes, today's PublishLog would look identical no matter which level "publish" was clicked at.

Question 1: What do we call this?

What do we call the thing we pressed publish on, to differentiate it from all the other things that were implicitly published?

Question 2: How do we handle multiples?

If we add a simple field to the PublishLog, we can track a single requested publish item, and use a null value to represent "the user clicked on publish-all". In the short term, I think this is the thing to do. But do we foresee a need to publish multiple, specific things at once? For instance, clicking multiple checkboxes on the search/browse screen and clicking "publish"? In that case, a M:M relation would make more sense here.

Question 3: How do we handle backfill?

We don't have this information, so how should we backfill it? Always assume the highest level? Have a different UX when we don't know?

[ChrisChV]

Question 1: What do we call this?

I suggest: publish_intent_entity, itent_entity, triggered_in

Question 2: How do we handle multiples?

Given that bulk publish (openedx/frontend-app-authoring#2798) is planned, where users can explicitly select multiple specific items to publish together, a single nullable FK may not be sufficient. A M:M relationship would be needed.

Question 3: How do we handle backfill?

I believe we should create a publish_scope and set the backfill value to "unknown". Now another question arises: why a new publish scope field? Because of the "Publish All" feature, that is also a special case that must be handled in UI . So, the publish_scope can be

• unknown: backfill, it is unknown what the user pressed.
• all: user clicked "Publish All".
• bulk: user selected multiple entities (bulk publish).
• single: user published a specific entity.

[ormsbee]

Question 1: What do we call this?

I suggest: publish_intent_entity, itent_entity, triggered_in

Or maybe selected_entities? I'd love for us to share terminology with UX/Product/documentation on this.

Question 2: How do we handle multiples?

Given that bulk publish (openedx/frontend-app-authoring#2798) is planned, where users can explicitly select multiple specific items to publish together, a single nullable FK may not be sufficient. A M:M relationship would be needed.

Ah, I hadn't seen that, but I completely agree that makes the M:M choice obvious.

Question 3: How do we handle backfill?

I believe we should create a publish_scope and set the backfill value to "unknown". Now another question arises: why a new publish scope field? Because of the "Publish All" feature, that is also a special case that must be handled in UI . So, the publish_scope can be

• unknown: backfill, it is unknown what the user pressed.
• all: user clicked "Publish All".
• bulk: user selected multiple entities (bulk publish).
• single: user published a specific entity.

What if we put a boolean field on PublishLogRecord and mark down for each record whether it was explicitly requested or not? It could be null for the initial "unknown" state before backfill, true if that record was explicitly requested, and false if it was implicitly published (e.g. because it was a child)?

The one drawback with the approach that I'm describing is that we couldn't differentiate later on between someone pressing "publish all" and "bulk publish by checking all the things that currently exist". @sdaitzman, @crathbun428: Is it okay to consider those things as equivalent, or is it important to differentiate them?