Closes T7943, Canceling calendar event should deactivate the event instead of destroying data.
Details
Details
- Reviewers
epriestley - Group Reviewers
Blessed Reviewers - Maniphest Tasks
- T7943: Make "Cancel Event" disable events
- Commits
- Restricted Diffusion Commit
rP0f914afda965: Canceling calendar events should deactivate the event
Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
One inline about STRICT_ALL_TABLES that we should double check in person.
| src/applications/calendar/controller/PhabricatorCalendarEventCancelController.php | ||
|---|---|---|
| 45–46 | You should also setContinueOnMissingFields(true) here. If we eventually add support for custom fields to events and an administrator adds a "required" custom field, adding this call will let the Editor know that it's still OK to cancel an event even if it doesn't have "Official Authorization Code (MANDATORY!!)" or whatever. (When creating or editing an event, the call is omitted because we do want the user to have to provide all required fields.) | |
| 71–72 | I think these are unused in this controller. | |
| src/applications/calendar/editor/PhabricatorCalendarEventEditor.php | ||
| 94 | This probably needs an (int): $object->setIsCancelled((int)$xaction->getNewValue()); We should configure STRICT_ALL_TABLES on your database so MySQL starts complaining about this. I can walk you through that. | |
| src/applications/calendar/storage/PhabricatorCalendarEvent.php | ||
| 260–266 | You can omit this block, the DestructionEngine will take care of it for you as long as you implement PhabricatorApplicationTransactionInterface (which you already implemented). Remainder of the method is good. | |