Final Todo Items
| Item | Status |
| 1. Add `End Time' to all scheduling dialogs, leaving `Duration there. This allows the user to choose to fill in either end time or duration, the latter being useful for items that span the 12AM boundary. End time and duration are edit-linked, meaning a confirmed change to one immediately affects the other. The definition of "confirmed change" in this context is that the change becomes confirmed when the user moves the mouse out of the field that was edited. | Pending |
| 2. Finish screen map in Section 2.1.4, including updating existing menu snapshots per latest menu changes. | Pending |
| 3. Finish up the "need to" item in Section 2.3.4.3. | Done |
| 4. Finish the Delay button biznis in Section 2.4.1. | Done |
| 5. Fix Pending Notifications subsection in meeting-scheduling to be consistent with latest meeting-scheduling options; clearly define "when conditions arise" in that section; if necessary, explain when notifications are downloaded | Done |
| 6. Change all occurrences of "not-yet-accepted" to "pending" throughout requirements entirely. Nixed this idea, after fixing list and filtering dialogs to say "not-yet-accepted" instead of "pending". | Done (fugawdaboudit) |
| 7. Fix meeting change-del-notifications to say that they're governed by the option setting for accepting penciled-ins. NO -- the user cannot turn off meeting change/del notifications with an option, the rationale being that once it's accepted, the users need to here about changes and deletes. | Done |
| 8. Fix change-del section to deal with the case of a not-yet-accepted being scheduler changed. I don't think this requires any new functionality. | Done |
| 9. Fix meeting sched and change-del sections to say that if a user declines or deletes a meeting, the system automatically discards any subsequent change/del notifications from the scheduler of that meeting. As noted [wherever] the system-wide identification of "that meeting" is uniquely determined by its Scheduler, Date, and Host fields. | Done |
| 10. Deal with how and when scheduler changes are visible to the user; i.e., are they automatically downloaded or do they stay on the central host? Let's say that "in effect" there are two local copies, one as most recently present on the user's calendar, including any local edits that may have been made, and the other copy being the one changed by the scheduler, from the scheduler's perspective. More precisely, it's the notification itself that contains the change information, in the form of a complete copy of the scheduler's version of the meeting, as of when the scheduler confirmed the change or delete operation. | Done |
11.
Add Scheduled and Pending checkboxes, default on, to bottom of meeting list
view; add the following to the bottom of the custom filter dialog:
Meeting State: O pending O scheduled O either | Done |
| 12. Fix whatever is necessary to be fixed about ordering of uniqueness-violating not-yet-accepted meetings. I think the only real reason for the uniqueness condition is total ordering in overlaps and lists, and if this is that case the easiest way to fix the ordering problem is to include, in the very rare cases where necessary, the Scheduled by, On, and Host fields as post-primary sort keys. | Done |
| 13. Finish admin section, in particular the central host biznis. | Done (at last!) |
| 14. Finish options narrative, and other parts as necessary (admin stuff). | Done |
| 15. Finish File section, and beyond. Keep it simple, stupid. | |
| 16. Deal with all work-in-progress items, then reduce this section to the following statement: "These requirements are currently stable. No work is in progress.". Go ahead and leave the narrative reference to it at the end of Section 2. | |
| 17. Finish non-functional and beyond, including appendices. Again, keep it simple. |