@JFernandez-WMF, I wrote up the new ticket for edit association after publication. Can you review it and tell me what you think? Also, I experimented with changing the instructional language, since I wondered if we could make it a bit more clear to the users what was happening. Let me know what you think of the updated language and if you have any ideas/suggestions for further improving it and if you think is more/less clear with the changes. Thanks in advance!

@ifried thank you, description of the task and copy look both good to me!

Great, thank you! This task is ready.

@JFernandez-WMF: Can you add mobile designs here when you get the chance?

I added the mobile designs — note that both desktop and mobile mockups are using the Codex dialog component, but we can use the OOUI component if that's the feasible way. Example of mobile with OOUI dialog:

Change #1182656 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] [WIP] Add edit association dialog

https://gerrit.wikimedia.org/r/1182656

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://554fabc3ca.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://27a4ec2259.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://554fabc3ca.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://ce2d28a2bc.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://2b7ac98b54.catalyst.wmcloud.org/w/

Test wiki on [[ | Patch demo ]] by CMelo (WMF) using patch(es) linked to this task was deleted:

https://2b7ac98b54.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by CMelo (WMF) using patch(es) linked to this task:
https://c55106d465.catalyst.wmcloud.org/w/

Test wiki on Patch demo by CMelo (WMF) using patch(es) linked to this task was deleted:

https://c55106d465.catalyst.wmcloud.org/w/

@JFernandez-WMF Hi! The selector in the task description appears to be full width in desktop, but that is not the default behaviour I got from Codex's select component. Am I missing something? Or, is it fine to leave it at its predefined width? Thanks!

Change #1182656 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add edit association dialog

https://gerrit.wikimedia.org/r/1182656

@Daimona hey! i believe that full-width behavior is possible within the codex dialog: https://doc.wikimedia.org/codex/latest/components/demos/dialog.html#with-form-inputs

In T400953#11225686, @JFernandez-WMF wrote:

@Daimona hey! i believe that full-width behavior is possible within the codex dialog: https://doc.wikimedia.org/codex/latest/components/demos/dialog.html#with-form-inputs

Interesting, thanks for the pointer! I checked that out, and while it is indeed full-width, this is achieved via a custom CSS rule in the demo code:

.cdx-demo-dialog-form-inputs {
	&__select {
		min-width: @size-full;
	}
}

(direct link)

Surely we can add the same rule, but if Codex wants selectors inside dialogs to be full-width, I imagine that would need to become a bundled style rule in Codex itself. Do you happen to have more context on why the demo is special-casing this?

• Given that an event has collaborative contributions tracking enabled,
  • And the a registered event participant is on a target wiki of the event,
    • And it is the date of the event,
      • And it is the time of the event,
        • And if they published an edit,
          • They should see a dialog appear after the publication
            • And if the user is registered for one active event, the dialog should have the following text:
              • ✅ Title in bold: "Associate this edit with an [name of event]"
              • ✅ Text below: "You are registered for an event that is active now. Is this edit for [event name]?"
              • ✅ And they will have the options of:
              • ✅ "No, thanks" (grey box)
              • ✅ "Yes" (blue box)
                
            • And if the user is registered for multiple active events, the dialog should have the following text:
              • ✅ "You are registered for multiple events that are active now. Is this edit for one of the events? If yes, please select which one."
              • ✅ Then, they should see a dropdown with "Select event," followed by potential event associations
              • ✅ And they will have the options of:
              • ✅ "No, thanks" (grey box)
              • ✅ "Yes" (blue box)
                

QA note - for the AC Title in bold: "Associate this edit with an [name of event]" , I believe the an here is a mistake in the AC, so just noting that here *

@Daimona The title says (desktop & mobile) but the task description says The implementation must work for both desktop and mobile experiences, but this ticket covers the desktop experience.

I am not seeing a separate task that creates the mobile UI experience, but I am not sure based on discrepancy between title and description whether that UI for the mobile dialog should be done in this ticket or not, so wondering if you'd like me to create a new task?

In T400953#11257961, @vaughnwalters wrote:

QA note - for the AC Title in bold: "Associate this edit with an [name of event]" , I believe the an here is a mistake in the AC, so just noting that here *

AC updated

@Daimona The title says (desktop & mobile) but the task description says The implementation must work for both desktop and mobile experiences, but this ticket covers the desktop experience.

I am not seeing a separate task that creates the mobile UI experience, but I am not sure based on discrepancy between title and description whether that UI for the mobile dialog should be done in this ticket or not, so wondering if you'd like me to create a new task?

I haven't heard of more work needing to be done for mobile here. The current dialog should work in both desktop and mobile anyway. Other than that I think it's a design question.

In T400953#11260745, @Daimona wrote:

In T400953#11257961, @vaughnwalters wrote:

QA note - for the AC Title in bold: "Associate this edit with an [name of event]" , I believe the an here is a mistake in the AC, so just noting that here *

AC updated

@Daimona The title says (desktop & mobile) but the task description says The implementation must work for both desktop and mobile experiences, but this ticket covers the desktop experience.

I am not seeing a separate task that creates the mobile UI experience, but I am not sure based on discrepancy between title and description whether that UI for the mobile dialog should be done in this ticket or not, so wondering if you'd like me to create a new task?

I haven't heard of more work needing to be done for mobile here. The current dialog should work in both desktop and mobile anyway. Other than that I think it's a design question.

It does function correctly, but I'm talking about the UI difference between the comp and the build for the dialog for the button layout for mobile.

comp	build (desktop with small breakpoint)	build (mobile skin)

In T400953#11261266, @vaughnwalters wrote:

It does function correctly, but I'm talking about the UI difference between the comp and the build for the dialog for the button layout for mobile.

Ah, I see. The Codex dialog doesn't seem to reposition buttons like that on mobile, not sure if it's intentional or maybe that was OOUI-only behaviour. Also a design question I think.

In T400953#11261581, @Daimona wrote:

In T400953#11261266, @vaughnwalters wrote:

It does function correctly, but I'm talking about the UI difference between the comp and the build for the dialog for the button layout for mobile.

Ah, I see. The Codex dialog doesn't seem to reposition buttons like that on mobile, not sure if it's intentional or maybe that was OOUI-only behaviour. Also a design question I think.

Okay since AC is met, I'll send this to @JFernandez-WMF for thoughts then on this.

thank you both! so, if im understanding correctly, right now in the work that's been done the buttons are stacked horizontally when on mobile - but the design stacks them vertically. is that correct?
if that's the case, i can ask codex folks about this, because the design was done using the mobile breakpoint of the component that's in place in figma

In T400953#11277658, @JFernandez-WMF wrote:

thank you both! so, if im understanding correctly, right now in the work that's been done the buttons are stacked horizontally when on mobile - but the design stacks them vertically. is that correct?
if that's the case, i can ask codex folks about this, because the design was done using the mobile breakpoint of the component that's in place in figma

Yep, that's correct. There doesn't seem to be breakpoint-based wrapping for Codex dialogs, while I seem to recall that it was a thing for OOUI. The docs have a section about stacking, but that's something we need to opt-in for specifically, and regardless of breakpoint (it would be the same in desktop); also it looks like it's meant to be used for long text, but the action texts in our dialog are short.

asked Codex folks: there's a task pending release that stacks buttons automatically at smaller breakpoint - so stacking will happen by default after the next release (see T399289: Make Dialog and Popover more responsive. everything else looks good, so moving to prod sign off