2020692 - Route Calendar Read Dialog Edit control through existing event editing

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, task, P3)

Description

[Martin Giger [:freaktechnik]]

When I am looking at an event I want an easy way to go to edit, if I'm allowed to edit it.

Comment 1

[Alex Schmitz]

This should work with both the new and old edit dialogs

Comment 3

[Alex Schmitz]

Summary:
Make the Read Dialog's Edit button open the event editor for the event being
shown. Bug 2070101 adds the button and decides when it is visible. This bug
connects that button to the existing code that opens an editor.

Use the editor choice supplied by Bug 2061188. This preserves the new-dialog
preference, the existing editor, and editing in a tab.

Links:

• Redux: Mapping to Existing Work
• Bug 2061188: Choose and open the event editor
• Bug 2061191: Shared event loader
• Bug 2070101: Add and show the Edit button

Acceptance criteria:

• Selecting Edit opens the editor for the event now shown in the read dialog.
• Close the read dialog only after the existing editor-opening code accepts
  the event. If the user cancels before that, keep the read dialog open.
• For a repeating event, keep the existing choice between Only this occurrence
  and All occurrences. The first choice edits the selected occurrence; the
  second edits the series. Pass the selected event or occurrence to that flow.
• With the new-dialog preference on, use the new editor. With it off, use the
  existing editor. Preserve editing in a tab where the existing setting applies.
• One Edit action opens one editor. A hidden or unavailable button cannot open
  an editor. After switching from event A to B, an old action for A must not
  open an editor for A.

Required implementation details:

• Use the current live event provided by the loader in Bug 2061191. Do not
  rebuild a live Calendar event from the Redux data copy.
• Keep that live event outside Redux. The Edit button's visibility comes from
  Redux updates in Bug 2070101; this story connects its action to the editor.
• Call the normal event-edit entry point from Bug 2061188. Do not add a second
  set of rules for choosing the editor.
• For the new dialog, the routing code supplies calendar-id and event-id, plus
  recurrence-id for a selected occurrence. It does not pass a preloaded event
  as the new dialog's state.
• Keep the existing recurring-event choice and transaction behavior. This bug
  connects to them; it does not implement new recurrence rules.

Minimum test coverage:

• Check the new-dialog preference on and off, and the existing edit-in-tab path.
• Check that a normal event opens with the correct calendar and event IDs.
• Check Only this occurrence and All occurrences for a repeating event,
  including the selected occurrence ID where needed.
• Check cancellation and that the read dialog closes only after the edit flow
  accepts the event.
• Check that one action opens one editor and hidden or unavailable actions do
  nothing.
• Switch from A to B and check that an old action for A cannot open its editor.
• Check that the existing live event reaches the edit entry point without
  rebuilding it from Redux data or storing it in Redux.

Out of scope:

• Adding or showing the Edit button, its Redux rendering, and preparing it
  before positioning; Bug 2070101 owns those parts.
• Adding or changing the preference and editor-choice rules in Bug 2061188.
• Changing editor fields, Save, recurrence rules, or Calendar transactions.

Comment 4

[Toby Pilling [:tobyp]]

I find the acceptance criteria a bit tricky to follow. If this bug doesn't include adding the controls, where is that happening? Can we include some details about "Only this occurrence" vs "All Occurrences"?

Comment 5

[Alex Schmitz]

Split the original scope as discussed:

• Bug 2070101 owns adding the Edit control and showing it only for the current editable source. Its rendering is Redux-update-driven and completes before positioning.
• This bug now owns routing that control through the existing event-edit entry point, so it follows the new-dialog preference, preserves edit-in-tab behavior, and falls back to the legacy editor.

The revised acceptance criteria explicitly preserve the selected recurring occurrence and the existing Only this occurrence versus All occurrences choice.

Comment 6

[Vineet Deo]

Attachment: Bug 2020692 - Calendar: Show event edit dialog from new calendar event dialog. r=#thunderbird-front-end-reviewers

How to Test

• Turn on the pref for the new calendar event dialog
• Create a single event, and a recurring event
• Open the single event, and click edit, it should open the edit dialog for that event
• Open a recurring event, it should show a prompt for selecting editing the occurrence, or editing all occurrences
• Editing the occurrence should show the the recurrence select disabled
• Editing all occurrences should show the recurrence select enabled
• Check that editing the event works as expected
• Turn on the calendar.event.createEditDialog.enabled pref
• Repeat above instructions, but check if the dialog has a recurrence-id if it is a single occurrence, otherwise it should not have a recurrence-id (attribute on the dialog)

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/a4c838d0dcb8
Calendar: Show event edit dialog from new calendar event dialog. r=tobyp,klamping