AppFlowy-IO/AppFlowy
1
0
Fork 0
mirror of https://github.com/AppFlowy-IO/AppFlowy.git synced 2026-03-24 12:56:59 +00:00
Code Issues 952 Projects Packages Wiki Activity

[GH-ISSUE #2380] [FR] Support weekly calendar #1011

New issue
Closed
opened 2026-03-23 20:44:24 +00:00 by mirror · 11 comments
mirror commented 2026-03-23 20:44:24 +00:00
Owner
Copy link

Originally created by @annieappflowy on GitHub (Apr 28, 2023).
Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/2380

Description

I'd like to have a weekly calendar to manage my weekly events and to-dos.

Impact

Calendar users who prefer to plan tasks by week

Additional Context

No response

Originally created by @annieappflowy on GitHub (Apr 28, 2023). Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/2380 ### Description I'd like to have a weekly calendar to manage my weekly events and to-dos. ### Impact Calendar users who prefer to plan tasks by week ### Additional Context _No response_
mirror 2026-03-23 20:44:24 +00:00
mirror commented 2026-03-23 20:44:25 +00:00
Author
Owner
Copy link

@hgkamath commented on GitHub (Jun 24, 2023):

Just attempting a more elaborate feature description of "A PLANNER" which is more than just a "Weekly calendar" / "Task scheduler"

Below, is a description of a paper-based planner-workflow system that many people do use after buying a paper based weekly-planner book. What is done by using pencil-marks, erasers, bookmarks and references should be mimicked by the digital system. My usage of this system is as best as I understand it. If you have used this system, you should be able to find mistakes in the intended flow.

I am sure other's will have their own variations to describe, that are similar to various paper-planner-schemes that are in use. It may be possibly to reconcile other systems with other planner-workflows, as long as they aren't inconsistent with one another, So that everyone can use their own planner-workflow.

PSGK v0.01 20230625 2380#issuecomment-1605653365 : A PLANNER SPECIFICATION (open spec)

  1. Should embed the data format for Planner-Data for a planner-period inside a RFC-5545 icalendar ical format-data-stream.
    • This is a key-distinguishing-feature.
    • The planner mechanism should live and be managed in the ical. As a direct benefit the daily scheduled entries and tasks are transparently rendered by ical presentation software. Adding/deleting/modifying daily scheduled entries from any icalendar-software should also work seamlessly and concurrently with app usage. The app should pull any changes and do some housekeeping to keep the planner features in order.
    • Its not a good idea to create/invent a new planner file-format which has its own encoding for storing events, be it even in .txt or .md, because this will only make calendar round-tripping more difficult, as it will later necessitate inter-conversion between one kind of scheduling-specification to another. This inter-conversion is not a simple computer engineering problem. Hence, it is better to first work within the limitations of the ical format, and later hack the ical format itself to store data needed in order to add any functionality beyond what it can already. Many other planner/calendar tools stalemate their development and fail at this ical round-tripping stage as well as in the support of multi-device synchronization. They end up restricting the user to only do export from to ical-calendar using their client-software from a single device.
    • Most ical calendar services can transparently upload and allow download of ical data without losing anything. As an add benefit, ical-services may optimize synchronization by using ical data entries with creation and modification timestamps. The timestamps allow quick identification of only those ical data entries that have changed.
    • Data can be stored inside an ical-task-description. The data format holding the properties inside the task description could be json (TBD)
    • Most non-scheduled, non-event, non-task data can also be stored either in a special-event-entries such as a midnight entry of 1st day of planning period, (ex: Jan-1 00:00am) or a special-task-entries in ical-tasks (ex: ZZpsgk000). Call this the common-block.
    • Software-client app-instance-specific settings, like layout defaults, could also be stored in their own special-entry-task/block for speedy retrieval. A list of clientname:software:taskname mappings could also be saved in the common block. ex (host123:appname:ZZtask001). Call this the client-settings-block. No use is intended as of now.
    • If an external file-format it absolutely needed for non-scheduled data (if any) its better to store them in a second ancillary file.
    • The ical format is a marked-up plain text format. If required, one could embed the ical file as a text-block inside a plain-text .txt or .md file.
  2. Should be able to configure the planning-period boundary (i.e. start of new planning year)
    • The planning-period is defined by its start-date and end-date
    • This essentially defines the planner-book. Different planner books will have different periods.
    • The common-block should have entries to store
      • planner-start-date: starting date of the planning-period in the book
      • planner-end-date: ending date of the planning-period in the book
    • Academic students may prefer August to be the start and July to be the end.
    • Some parts of the world may prefer start of spring (Mar-1/Apr-1/Feb-10=Chinese new year/configurable) as start of a new year or even use the luni-solar-calendar or lunar-calendar and so the start date on the solar-calendar varies from year to year.
    • Most working adults prefer Jan-1 to be start of new year to coincide with administrative and tax calendars.
    • Typically, planner period is 1 year. But a busier person may prefer half-yearly.
    • The ability to set planner period can also help in transitioning between an academic year to a fiscal new year by having a 5-month (Aug-Dec) planner-period to bridge the two.
  3. Should ensure the planner-book has a name/identifier, as well as forward and backward references, in order to help with automated browsing across planner-period-boundaries
    • identifiers could be 2-letter series identifier followed by a planner-start-date ex: aa20230101
      • This makes planner book naming trivial, next successive planner book can be deduced from its planner-start-date.
      • Typically, a person only ever needs one series.
    • The common-block should have entries to store
      • planner-book-name: name/identifier of current-planner-book
      • previous-planner-book: name/identifier of previous-period-planner-book
        • The field is empty if a previous-planner-book does not exist.
      • next-planner-book: name/identifier of next-period-planner-book
        • The field is empty if a next-planner-book does not exist.
        • The next-planner-book's planner-start-date is usually the next day of the planner-end-date of the current book.
        • The next-planner-book's planner-start-date must not be less than the current-planner-book's end-date
        • As long as the next planner book is not created, the planner-end-date of a previous book should not be allowed to be changed easily. Tampering with end/start dates after a planner-book is created requires more care.
  4. Should have a concept of role
    • example roles: parent-of, child-of, spouse, extended-family, neighbor, pet-owner, work-1, work-2, group-participation-1 ... , group-participation-2, ... , citizen, student, research, self-improvement, self-leisure
    • Every task (project/hierarchy/subtaskname) is done within the context of a role.
  5. Should have an concept of project, subtask and scheduled-entry as follows
    • A subtask is essentially a todo-item, something that must be worked on and scheduled, usually resides in the task list
    • Subtasks have the following properties
      • task-state(active/inactive), priority(A/B/C/D), completion-state, no-longer-bring-forward-flag, role
      • entry descriptor for 4-quadrant identifier for: important/unimportant + immediate/deffer-able
      • expected duration, percentage-completed, deferred, deferred-reason, waiting-on, waited-on-by
    • Projects are a logical grouping of subprojects and subtasks
      • Projects can form a hierarchy, but not a cycle
      • Projectnames including those of subprojects are unique
      • A project or subtask can have only one unique parent. (maybe relaxable, unsure)
      • A project has within in list of subprojects and a list of its own subtasks
    • An entry is that which is scheduled and shown in the periodic-sheets daily-task-entries.
      • It could be either be an event or a time duration allocated to work on a project/subtask
        • events usually are commitments made as part of role/project (ex attending colloquiums), group-meeting, tennis-practice etc. Its not always necessary to have an assoiciated subtask. The subtask to participate in events is implicit.
    • An entry should have a title, description, start-time, duration-info, location-info, recurring-info,
  6. Should be visually presented as sections
    • GUI could be in a side-bar or tabs
  7. Should have a section for defining roles
    • The defied roles are stored in the ical's common-block
  8. Should have a section for configuring projects and subtasks
    • The projects are stored as task-entries in the ical
  9. Should have a section for custom-sheets (maybe 9. and 10. could merge?)
    • These sheets are similar to blank paper sheets
    • These could be links to sheets elsewhere in the app, but it is useful to consolidate them inside the planner-book.
    • This are used to save for quick-reference/emergency, personal/private information of self/family members/assets etc.
    • The blank sheets are stored as task-entries in the ical with prefix ZZSP_pb<pbid>_ ex ZZSP_pb<pbid>_INFO
    • The common-block should have an entry for list of custom-sheets
  10. Should have a section for archive-able special sheets such as mission, vision, goals statements
    • These section views should look like a sheet of paper
    • Goals, mission, vision are not the same as projects or subtasks
      • These set direction for personal growth and higher purposes in various roles.
      • They guide what projects one might choose to do.
      • The baser simplest of goals may be interpreted as a performance target or milestones for some activities.
    • One should be able to review/edit
      • After having edited, a user is expected to distinguish between a major change and minor changes.
      • If it is a major change then before over-writing, the older statement should be date-stamped/archived.
    • A subtask entry is usually described by name. The project hierarchy part is optional as it may not make sense to have concepts of project at the goal level.
    • When a subtask entry is first created, entries are created in the ical-task-list. Usually, entries in this section are not scheduled, but doesn't hurt to keep the schedule-ability-features, The default behavior during entry creation need not require completion of time, date,recurrence fields.
    • Entries on the sheet should be sortable by role/priority, optionally group-split by the task-state , or hide one or the other
    • The view should be filterable so as to focus on fewer relevant entries. The filtered-out entries can be pushed to the bottom, greyed-out and/or made invisible.
    • These sheets are mandatorily archived on a planner-books planning-period-boundary (ex: every year), even if no change/edit.
    • One should be able to go back in time to see sheets of older archived statements.
    • The special sheets are stored as task-entries in the ical with prefix ZZSP_pb<pbid>_dt<mmdd>_ ex ZZSH_PBaa20230101_DT1231_VISION
      • DT0000 can be used to refer to the default undatestamped sheet.
    • The common-block should have an entry for the list of special-sheets
  11. Should have a section for periodic sheets
    • These section views should look like ruled sheets of paper, with checkbox and other indicators for completion, priority
    • Periodic sheets contain the todos(tasks):
    • Periodic sheets are used to keep todo-s for various time-spans
    • Time-spans include daily/weekly/fortnightly/monthly/semi-annually/yearly/biennially/4-yearly/longterm
      • Yes, the event-start, event-duration, event-recurrence could lie beyond the planning-period of the planner-book.
      • Later, it will be described how planner Housekeeping, will make some alterations.
    • The default view is the daily-periodic-sheet in daily-tasks-by-day view, set to "today"
    • A subtask entry is fully described by project/hierarchy/subtaskname
    • When a subtask entry is first created, entries are created in the ical-task-list and are optionally scheduled. A task is taken up during a time scheduled for tasks of that role/project. An entry becomes inactive when no future scheduled event exists in which it can be taken up, such as time set aside for working on a prefix of projectP1/SP1/SSP1/hierarchy,
    • Entries on the sheet should be sortable by role/priority, optionally group-split by the task-state , or hide one or the other
    • The view should be filterable so as to focus on fewer relevant entries. The filtered-out entries can be pushed to the bottom, greyed-out and/or made invisible.
    • When an entry is marked as completed,
      • It is indicated by a check sign (an incomplete task may have a v-center-dot)
      • The entry's "no-longer-bring-forward-flag" is also set.
      • In some orderings, completed entries should be push-able to the bottom in the list with other completed tasks, as it no longer competes for focus.
    • The daily periodic sheet is special in that, in addition to list of daily-task-entries-by-day, it should also have following additional views listed below
      • The additional views include
        • daily-task-entries-by-day but also over longer time-spans such as daily-task-entries-by-week and daily-task-entries-by-month.
          • The daily-task-entries-by-week is what you would call the WEEKLY-CALENDAR.
          • The daily-task-entries-by-month is what you would call the MONTHLY-CALENDAR.
        • Each of these views mentioned has a corresponding hourly schedule view, wherein tasks in active state in the day are visualized by placing them as blocks at nearest half-hourly points.
      • These views are different from the weekly monthly and other periodic sheets. These views contain the same daily-entries.
        • The tasks-by-day is like a single ruled sheet
        • The tasks-by-week shows the same daily tasks of 7 days in a 7-column sheet
        • the tasks-by-month shows the same daily tasks arranged in a grid of 5-row-7-column sheet
      • These views should look similar to a sheet of paper
      • Ability to sort the views of the todo/task list by role/priority, optionally group-split by the task-state , or hide one or the other
      • These view should also be filterable so as to focus on fewer relevant entries. The filtered-out entries can be pushed to the bottom, greyed-out and/or made invisible.
    • One should be able to browse forward and backwards in time
    • BRING-FORWARD/POPULATE SHEET FEATURE
      • Normally, a new periodic-sheet should be blank except for events that have a recurrence in that period.
      • When a user has decided a period (day,week, month) has ended, user goes to new sheet and presses populate-sheet-button,
        • If recurring tasks are missing in that period-sheet, they are to be re-populated
        • All tasks from last period (day/week/month...) that were marked not-completed and no-longer-bring-forward-flag is unchecked will be copied to the next period, and its task-state will be reset to in-active state. If future page exists, the user must manually reconcile.
  12. Should perform housekeeping when the planner-book is opened when current-time is beyond the planning-period-boundary (end-date) of the planner-book.
    • An entry in the common-block could store
      • housekeeping-already-done: to indicate whether housekeeping has already been done before
        • The settings needs needs to be cleared to false in order to allow rerun housekeeping.
    • After present time passes the the planning-period-end-date boundary (ex: a year boundary, such as the New Year, the day after Dec 31st) and the setting housekeeping-already-done is not set.
      • If the next-period-planner-book entry is not set, or if next-period-planner-book cannot be found, a new planning-period planner-book should be created and opened.
        • The planning-period of the new book, can be inferred to be same-duration as but continuing from the past-planning-period
      • This ensures that when a planning-book for a planning-period is opened, the software only has to process those events in the current planning-period.
      • Special sheets and Custom sheets should be copied (allowing those in the previous period to be archived)
      • Recurring events should be recreated in the sheet for the new year, with the same recurrence.
      • Unfinished project/hierarchy/subtasks should be copied from the previous-planning-period
      • An event that spans across the period boundary is broken into two, one in each planning-period.
      • The new planner book will keep the link to the ical
      • set the previous planning period variable
    • In the past planning-period planner-book
      • The recurring events of the past year should be ended.
      • Then the past planning-period planner-book should be archived.
      • set housekeeping-already-done variable
      • set the next-planning-period variable
    • If a planner period book is being opened, the planner period book is opened in a special edit mode
      • This edit mode requires verification and confirmation as every edit as these are changes to records of the past, and can potentially introduce discontinuity into the next planner-period planner-book. Correcting typos, information, description are less problematic. Changing completion status, recurrence schedules etc are more problematic
      • As a general rule, one should not edit passed-period planner-books.
      • The old planner book should no longer automatically synchronize with ical.
    • This allows a year-wise archival system of planner books.
  13. Optionally as a subfeature integrate with a TIME-TRACKER plugin
    • A role/project/subtask is associated with one in the time tracker plugin
    • Scheduling a subtask in the today sheet, should change the task-state to active, automatically notify time-tracker plugin to track time spent on the role/project/subtask. Time tracking stops when subtask is ended in time-tracker. As a person can't be working on two things simultaneously, starting a different subtask could stop the subtask currently tracked by the timetracker.
  14. Should be able to do CALENDAR SYNCING:
    • Ability to sync with ical/caldav/google-calendar
    • A planner-book should sync events only within its planner-period (start-date to end-date)
    • At the start, a sanity check operation can
      • check old planner-book closure, that is whether
        • recurring events created in past period have been ended,
        • tasks created in past period have also been ended (no-longer-bring-forward set).
      • ask and confirm to ensure closure.
    • round-trip syncing of RFC-5545 icalendar
    • https://datatracker.ietf.org/doc/html/rfc5545
  15. Should have the ability to export data
    • export options include:
      • planner-year-book
      • periodic-sheet-ranges
      • individual sheets
    • export to formats : markdown, pdf, ical/icsfile

Essence of this planner system:

  • A person, has roles in life
  • A person, has a vision, mission and goals pertaining to these roles and needs to review these often
  • A person, in each role, has a hierarchy of projects, each of which have subtasks
  • A person, has at any given time a limited number of tasks can be worked on
  • A person, must ahead of time make a schedule and plan their time, so as when to do a role/project
  • A person, when it is time to execute, needs to see what has to be done for the day, and what subtasks can be done for any given time.
    • In the time slot for the role/project, a person works on a subtask that leads to its completion
  • goals, projects, subtasks have relative priorities, they have deadlines, they need resources, someone else maybe waiting on you to deliver results them.
  • long term deadlines must be reviewable.
  • In the paper system, a person carries all the future sheets a person needs, often up to two months ahead.
  • The planner system is self-documenting, itself records on what roles/projects/subtasks, a person used their time in a giving planning period.
  • Spacial placement of scheduled-events and todo-subtasks is important as it helps visualization of time.

Advantage of Paper over Digital

  • The finite size of paper, and the limited-ability-carry forces a person to be economical on what to note.
  • The tediousness of copying uncompleted tasks does make a user think whether the task itself was necessary, and encourages more pragmatic goals and task culling.
  • Does not need an operational computer or electricity to use.
  • Coloring and stickers allow for personalization.
  • Secure to the extent the owner physically takes care of the planner

Advantage of Digital over Paper

  • Automate the tedious-task of having to copy goals/projects/subtasks
  • Low priority unattended sub-tasks can projects can be identified and the view can be de-cluttered.
  • Its possible to document, log many comments and yet still have them out of view, not cluttering the planning-views.
  • Secure to the extent one follows computer-security guidelines and backs-up data.

Notes:

  • The WEEKLY-CALENDAR / MONTHLY-CALENDAR are just a view of a daily planner sheets. A PLANNER does much more.
  • Being able to go back and forward in time is important to see/study how things panned out, plan and schedule for the future
  • The following could be sub-features to achieve later
    • ENTRY-SEARCH
    • ADV-ENTRY-FILTERING in view
    • INTEGRATION WITH TIME-TRACKER
    • CALENDAR-SYNCING
    • INTEGRATION WITH PROJECT-PLANNER
    • ANALYSIS, VISUALIZATION and REPORTS to study activities per role or project
    • COLLABORATION/GROUP FEATURES
<!-- gh-comment-id:1605653365 --> @hgkamath commented on GitHub (Jun 24, 2023): Just attempting a more elaborate feature description of "**A PLANNER**" which is more than just a "Weekly calendar" / "Task scheduler" Below, is a description of a paper-based planner-workflow system that many people do use after buying a paper based weekly-planner book. What is done by using pencil-marks, erasers, bookmarks and references should be mimicked by the digital system. My usage of this system is as best as I understand it. If you have used this system, you should be able to find mistakes in the intended flow. I am sure other's will have their own variations to describe, that are similar to various paper-planner-schemes that are in use. It may be possibly to reconcile other systems with other planner-workflows, as long as they aren't inconsistent with one another, So that everyone can use their own planner-workflow. **PSGK** v0.01 20230625 [2380#issuecomment-1605653365](https://github.com/AppFlowy-IO/AppFlowy/issues/2380#issuecomment-1605653365) : A PLANNER SPECIFICATION (open spec) 1. Should embed the data format for Planner-Data for a planner-period inside a [RFC-5545](https://datatracker.ietf.org/doc/html/rfc5545) icalendar ical format-data-stream. - This is a **key-distinguishing-feature**. - The planner mechanism should live and be managed in the ical. As a direct benefit the daily scheduled entries and tasks are transparently rendered by ical presentation software. Adding/deleting/modifying daily scheduled entries from any icalendar-software should also work seamlessly and concurrently with app usage. The app should pull any changes and do some housekeeping to keep the planner features in order. - Its not a good idea to create/invent a new planner file-format which has its own encoding for storing events, be it even in .txt or .md, because this will only make calendar round-tripping more difficult, as it will later necessitate inter-conversion between one kind of scheduling-specification to another. This inter-conversion is not a simple computer engineering problem. Hence, it is better to first work within the limitations of the ical format, and later hack the ical format itself to store data needed in order to add any functionality beyond what it can already. Many other planner/calendar tools stalemate their development and fail at this ical round-tripping stage as well as in the support of multi-device synchronization. They end up restricting the user to only do export from to ical-calendar using their client-software from a single device. - Most ical calendar services can transparently upload and allow download of ical data without losing anything. As an add benefit, ical-services may optimize synchronization by using ical data entries with creation and modification timestamps. The timestamps allow quick identification of only those ical data entries that have changed. - Data can be stored inside an ical-task-description. The data format holding the properties inside the task description could be json (TBD) - Most non-scheduled, non-event, non-task data can also be stored either in a special-event-entries such as a midnight entry of 1st day of planning period, (ex: Jan-1 00:00am) or a special-task-entries in ical-tasks (ex: ZZpsgk000). Call this the common-block. - Software-client app-instance-specific settings, like layout defaults, could also be stored in their own special-entry-task/block for speedy retrieval. A list of clientname:software:taskname mappings could also be saved in the common block. ex (host123:appname:ZZtask001). Call this the client-settings-block. No use is intended as of now. - If an external file-format it absolutely needed for non-scheduled data (if any) its better to store them in a second ancillary file. - The ical format is a marked-up plain text format. If required, one could embed the ical file as a text-block inside a plain-text .txt or .md file. 2. Should be able to configure the planning-period boundary (i.e. start of new planning year) - The planning-period is defined by its start-date and end-date - This essentially defines the planner-book. Different planner books will have different periods. - The common-block should have entries to store - planner-start-date: starting date of the planning-period in the book - planner-end-date: ending date of the planning-period in the book - Academic students may prefer August to be the start and July to be the end. - Some parts of the world may prefer start of spring (Mar-1/Apr-1/Feb-10=Chinese new year/configurable) as start of a new year or even use the luni-solar-calendar or lunar-calendar and so the start date on the solar-calendar varies from year to year. - Most working adults prefer Jan-1 to be start of new year to coincide with administrative and tax calendars. - Typically, planner period is 1 year. But a busier person may prefer half-yearly. - The ability to set planner period can also help in transitioning between an academic year to a fiscal new year by having a 5-month (Aug-Dec) planner-period to bridge the two. 3. Should ensure the planner-book has a name/identifier, as well as forward and backward references, in order to help with automated browsing across planner-period-boundaries - identifiers could be 2-letter series identifier followed by a planner-start-date ex: aa20230101 - This makes planner book naming trivial, next successive planner book can be deduced from its planner-start-date. - Typically, a person only ever needs one series. - The common-block should have entries to store - planner-book-name: name/identifier of current-planner-book - previous-planner-book: name/identifier of previous-period-planner-book - The field is empty if a previous-planner-book does not exist. - next-planner-book: name/identifier of next-period-planner-book - The field is empty if a next-planner-book does not exist. - The next-planner-book's planner-start-date is usually the next day of the planner-end-date of the current book. - The next-planner-book's planner-start-date must not be less than the current-planner-book's end-date - As long as the next planner book is not created, the planner-end-date of a previous book should not be allowed to be changed easily. Tampering with end/start dates after a planner-book is created requires more care. 4. Should have a concept of role - example roles: parent-of, child-of, spouse, extended-family, neighbor, pet-owner, work-1, work-2, group-participation-1 ... , group-participation-2, ... , citizen, student, research, self-improvement, self-leisure - Every task (project/hierarchy/subtaskname) is done within the context of a role. 5. Should have an concept of project, subtask and scheduled-entry as follows - A subtask is essentially a todo-item, something that must be worked on and scheduled, usually resides in the task list - Subtasks have the following properties - task-state(active/inactive), priority(A/B/C/D), completion-state, no-longer-bring-forward-flag, role - entry descriptor for 4-quadrant identifier for: important/unimportant + immediate/deffer-able - expected duration, percentage-completed, deferred, deferred-reason, waiting-on, waited-on-by - Projects are a logical grouping of subprojects and subtasks - Projects can form a hierarchy, but not a cycle - Projectnames including those of subprojects are unique - A project or subtask can have only one unique parent. (maybe relaxable, unsure) - A project has within in list of subprojects and a list of its own subtasks - An entry is that which is scheduled and shown in the periodic-sheets daily-task-entries. - It could be either be an event or a time duration allocated to work on a project/subtask - events usually are commitments made as part of role/project (ex attending colloquiums), group-meeting, tennis-practice etc. Its not always necessary to have an assoiciated subtask. The subtask to participate in events is implicit. - An entry should have a title, description, start-time, duration-info, location-info, recurring-info, 6. Should be visually presented as sections - GUI could be in a side-bar or tabs 7. Should have a section for defining roles - The defied roles are stored in the ical's common-block 8. Should have a section for configuring projects and subtasks - The projects are stored as task-entries in the ical 9. Should have a section for custom-sheets (maybe 9. and 10. could merge?) - These sheets are similar to blank paper sheets - These could be links to sheets elsewhere in the app, but it is useful to consolidate them inside the planner-book. - This are used to save for quick-reference/emergency, personal/private information of self/family members/assets etc. - The blank sheets are stored as task-entries in the ical with prefix ZZSP_pb\<pbid>_ ex ZZSP_pb\<pbid>\_INFO - The common-block should have an entry for list of custom-sheets 10. Should have a section for archive-able special sheets such as mission, vision, goals statements - These section views should look like a sheet of paper - Goals, mission, vision are not the same as projects or subtasks - These set direction for personal growth and higher purposes in various roles. - They guide what projects one might choose to do. - The baser simplest of goals may be interpreted as a performance target or milestones for some activities. - One should be able to review/edit - After having edited, a user is expected to distinguish between a major change and minor changes. - If it is a major change then before over-writing, the older statement should be date-stamped/archived. - A subtask entry is usually described by name. The project hierarchy part is optional as it may not make sense to have concepts of project at the goal level. - When a subtask entry is first created, entries are created in the ical-task-list. Usually, entries in this section are not scheduled, but doesn't hurt to keep the schedule-ability-features, The default behavior during entry creation need not require completion of time, date,recurrence fields. - Entries on the sheet should be sortable by role/priority, optionally group-split by the task-state , or hide one or the other - The view should be filterable so as to focus on fewer relevant entries. The filtered-out entries can be pushed to the bottom, greyed-out and/or made invisible. - These sheets are mandatorily archived on a planner-books planning-period-boundary (ex: every year), even if no change/edit. - One should be able to go back in time to see sheets of older archived statements. - The special sheets are stored as task-entries in the ical with prefix ZZSP_pb\<pbid>\_dt\<mmdd>_ ex ZZSH_PBaa20230101_DT1231_VISION - DT0000 can be used to refer to the default undatestamped sheet. - The common-block should have an entry for the list of special-sheets 11. Should have a section for periodic sheets - These section views should look like ruled sheets of paper, with checkbox and other indicators for completion, priority - Periodic sheets contain the todos(tasks): - Periodic sheets are used to keep todo-s for various time-spans - Time-spans include daily/weekly/fortnightly/monthly/semi-annually/yearly/biennially/4-yearly/longterm - Yes, the event-start, event-duration, event-recurrence could lie beyond the planning-period of the planner-book. - Later, it will be described how planner Housekeeping, will make some alterations. - The default view is the daily-periodic-sheet in daily-tasks-by-day view, set to "today" - A subtask entry is fully described by project/hierarchy/subtaskname - When a subtask entry is first created, entries are created in the ical-task-list and are optionally scheduled. A task is taken up during a time scheduled for tasks of that role/project. An entry becomes inactive when no future scheduled event exists in which it can be taken up, such as time set aside for working on a prefix of projectP1/SP1/SSP1/hierarchy, - Entries on the sheet should be sortable by role/priority, optionally group-split by the task-state , or hide one or the other - The view should be filterable so as to focus on fewer relevant entries. The filtered-out entries can be pushed to the bottom, greyed-out and/or made invisible. - When an entry is marked as completed, - It is indicated by a check sign (an incomplete task may have a v-center-dot) - The entry's "no-longer-bring-forward-flag" is also set. - In some orderings, completed entries should be push-able to the bottom in the list with other completed tasks, as it no longer competes for focus. - The daily periodic sheet is special in that, in addition to list of daily-task-entries-by-day, it should also have following additional views listed below - The additional views include - daily-task-entries-by-day but also over longer time-spans such as daily-task-entries-by-week and daily-task-entries-by-month. - The daily-task-entries-by-week is what you would call the WEEKLY-CALENDAR. - The daily-task-entries-by-month is what you would call the MONTHLY-CALENDAR. - Each of these views mentioned has a corresponding hourly schedule view, wherein tasks in active state in the day are visualized by placing them as blocks at nearest half-hourly points. - These views are different from the weekly monthly and other periodic sheets. These views contain the same daily-entries. - The tasks-by-day is like a single ruled sheet - The tasks-by-week shows the same daily tasks of 7 days in a 7-column sheet - the tasks-by-month shows the same daily tasks arranged in a grid of 5-row-7-column sheet - These views should look similar to a sheet of paper - Ability to sort the views of the todo/task list by role/priority, optionally group-split by the task-state , or hide one or the other - These view should also be filterable so as to focus on fewer relevant entries. The filtered-out entries can be pushed to the bottom, greyed-out and/or made invisible. - One should be able to browse forward and backwards in time - BRING-FORWARD/POPULATE SHEET FEATURE - Normally, a new periodic-sheet should be blank except for events that have a recurrence in that period. - When a user has decided a period (day,week, month) has ended, user goes to new sheet and presses populate-sheet-button, - If recurring tasks are missing in that period-sheet, they are to be re-populated - All tasks from last period (day/week/month...) that were marked not-completed and no-longer-bring-forward-flag is unchecked will be copied to the next period, and its task-state will be reset to in-active state. If future page exists, the user must manually reconcile. 12. Should perform housekeeping when the planner-book is opened when current-time is beyond the planning-period-boundary (end-date) of the planner-book. - An entry in the common-block could store - housekeeping-already-done: to indicate whether housekeeping has already been done before - The settings needs needs to be cleared to false in order to allow rerun housekeeping. - After present time passes the the planning-period-end-date boundary (ex: a year boundary, such as the New Year, the day after Dec 31st) and the setting housekeeping-already-done is not set. - If the next-period-planner-book entry is not set, or if next-period-planner-book cannot be found, a new planning-period planner-book should be created and opened. - The planning-period of the new book, can be inferred to be same-duration as but continuing from the past-planning-period - This ensures that when a planning-book for a planning-period is opened, the software only has to process those events in the current planning-period. - Special sheets and Custom sheets should be copied (allowing those in the previous period to be archived) - Recurring events should be recreated in the sheet for the new year, with the same recurrence. - Unfinished project/hierarchy/subtasks should be copied from the previous-planning-period - An event that spans across the period boundary is broken into two, one in each planning-period. - The new planner book will keep the link to the ical - set the previous planning period variable - In the past planning-period planner-book - The recurring events of the past year should be ended. - Then the past planning-period planner-book should be archived. - set housekeeping-already-done variable - set the next-planning-period variable - If a planner period book is being opened, the planner period book is opened in a special edit mode - This edit mode requires verification and confirmation as every edit as these are changes to records of the past, and can potentially introduce discontinuity into the next planner-period planner-book. Correcting typos, information, description are less problematic. Changing completion status, recurrence schedules etc are more problematic - As a general rule, one should not edit passed-period planner-books. - The old planner book should no longer automatically synchronize with ical. - This allows a year-wise archival system of planner books. 13. Optionally as a subfeature integrate with a TIME-TRACKER plugin - A role/project/subtask is associated with one in the time tracker plugin - Scheduling a subtask in the today sheet, should change the task-state to active, automatically notify time-tracker plugin to track time spent on the role/project/subtask. Time tracking stops when subtask is ended in time-tracker. As a person can't be working on two things simultaneously, starting a different subtask could stop the subtask currently tracked by the timetracker. 14. Should be able to do CALENDAR SYNCING: - Ability to sync with ical/caldav/google-calendar - A planner-book should sync events only within its planner-period (start-date to end-date) - At the start, a sanity check operation can - check old planner-book closure, that is whether - recurring events created in past period have been ended, - tasks created in past period have also been ended (no-longer-bring-forward set). - ask and confirm to ensure closure. - round-trip syncing of RFC-5545 icalendar - https://datatracker.ietf.org/doc/html/rfc5545 15. Should have the ability to export data - export options include: - planner-year-book - periodic-sheet-ranges - individual sheets - export to formats : markdown, pdf, ical/icsfile **Essence of this planner system**: - A person, has roles in life - A person, has a vision, mission and goals pertaining to these roles and needs to review these often - A person, in each role, has a hierarchy of projects, each of which have subtasks - A person, has at any given time a limited number of tasks can be worked on - A person, must ahead of time make a schedule and plan their time, so as when to do a role/project - A person, when it is time to execute, needs to see what has to be done for the day, and what subtasks can be done for any given time. - In the time slot for the role/project, a person works on a subtask that leads to its completion - goals, projects, subtasks have relative priorities, they have deadlines, they need resources, someone else maybe waiting on you to deliver results them. - long term deadlines must be reviewable. - In the paper system, a person carries all the future sheets a person needs, often up to two months ahead. - The planner system is self-documenting, itself records on what roles/projects/subtasks, a person used their time in a giving planning period. - Spacial placement of scheduled-events and todo-subtasks is important as it helps visualization of time. Advantage of Paper over Digital - The finite size of paper, and the limited-ability-carry forces a person to be economical on what to note. - The tediousness of copying uncompleted tasks does make a user think whether the task itself was necessary, and encourages more pragmatic goals and task culling. - Does not need an operational computer or electricity to use. - Coloring and stickers allow for personalization. - Secure to the extent the owner physically takes care of the planner Advantage of Digital over Paper - Automate the tedious-task of having to copy goals/projects/subtasks - Low priority unattended sub-tasks can projects can be identified and the view can be de-cluttered. - Its possible to document, log many comments and yet still have them out of view, not cluttering the planning-views. - Secure to the extent one follows computer-security guidelines and backs-up data. **Notes**: - The WEEKLY-CALENDAR / MONTHLY-CALENDAR are just a view of a daily planner sheets. A PLANNER does much more. - Being able to go back and forward in time is important to see/study how things panned out, plan and schedule for the future - The following could be sub-features to achieve later - ENTRY-SEARCH - ADV-ENTRY-FILTERING in view - INTEGRATION WITH TIME-TRACKER - CALENDAR-SYNCING - INTEGRATION WITH PROJECT-PLANNER - ANALYSIS, VISUALIZATION and REPORTS to study activities per role or project - COLLABORATION/GROUP FEATURES
mirror commented 2026-03-23 20:44:25 +00:00
Author
Owner
Copy link

@wwwdyne commented on GitHub (Sep 8, 2024):

Recurring task is a killer-feature of Notion's calendar.
@hgkamath @annieappflowy
Is it possible to implement it in AppFlowy this year?
Please add it to the roadmap for 2024.

<!-- gh-comment-id:2336604913 --> @wwwdyne commented on GitHub (Sep 8, 2024): Recurring task is a killer-feature of Notion's calendar. @hgkamath @annieappflowy Is it possible to implement it in AppFlowy this year? Please add it to the roadmap for 2024.
mirror commented 2026-03-23 20:44:25 +00:00
Author
Owner
Copy link

@Artemis1-0 commented on GitHub (May 25, 2025):

This would be huge, for people who want this sort of functionality (me) and for progressing the integration with 3rd party calendar services like google calendar (also me).

<!-- gh-comment-id:2907759491 --> @Artemis1-0 commented on GitHub (May 25, 2025): This would be huge, for people who want this sort of functionality (me) and for progressing the integration with 3rd party calendar services like google calendar (also me).
mirror commented 2026-03-23 20:44:26 +00:00
Author
Owner
Copy link

@Miyake-Diogo commented on GitHub (Jul 30, 2025):

I think the option to create a daily note integrate with calendar like Affine PRO could be a good feature included at this FR.

<!-- gh-comment-id:3136593344 --> @Miyake-Diogo commented on GitHub (Jul 30, 2025): I think the option to create a daily note integrate with calendar like Affine PRO could be a good feature included at this FR.
mirror commented 2026-03-23 20:44:26 +00:00
Author
Owner
Copy link

@arigit commented on GitHub (Sep 7, 2025):

I think the option to create a daily note integrate with calendar like Affine PRO could be a good feature included at this FR.

also logseq took the "daily note" approach and it works really well. Miss that in appflowy.

<!-- gh-comment-id:3263975180 --> @arigit commented on GitHub (Sep 7, 2025): > I think the option to create a daily note integrate with calendar like Affine PRO could be a good feature included at this FR. also logseq took the "daily note" approach and it works really well. Miss that in appflowy.
mirror commented 2026-03-23 20:44:26 +00:00
Author
Owner
Copy link

@annieappflowy commented on GitHub (Sep 12, 2025):

This feature is available in our web app (appflowy.com)

<!-- gh-comment-id:3283560345 --> @annieappflowy commented on GitHub (Sep 12, 2025): This feature is available in our web app (appflowy.com)
mirror commented 2026-03-23 20:44:26 +00:00
Author
Owner
Copy link

@Artemis1-0 commented on GitHub (Sep 12, 2025):

I'm taking that this is also now in the main app as well???

<!-- gh-comment-id:3284021779 --> @Artemis1-0 commented on GitHub (Sep 12, 2025): I'm taking that this is also now in the main app as well???
mirror commented 2026-03-23 20:44:27 +00:00
Author
Owner
Copy link

@annieappflowy commented on GitHub (Sep 12, 2025):

I'm taking that this is also now in the main app as well???

It's only in the web app.
The main flutter app only has the monthly view due to the limitation of the third party flutter library.

<!-- gh-comment-id:3284053515 --> @annieappflowy commented on GitHub (Sep 12, 2025): > I'm taking that this is also now in the main app as well??? It's only in the web app. The main flutter app only has the monthly view due to the limitation of the third party flutter library.
mirror commented 2026-03-23 20:44:27 +00:00
Author
Owner
Copy link

@Artemis1-0 commented on GitHub (Sep 12, 2025):

I see. What ways could this be implemented then?

<!-- gh-comment-id:3285650898 --> @Artemis1-0 commented on GitHub (Sep 12, 2025): I see. What ways could this be implemented then?
mirror commented 2026-03-23 20:44:27 +00:00
Author
Owner
Copy link

@annieappflowy commented on GitHub (Sep 12, 2025):

I see. What ways could this be implemented then?

We write a flutter cal library

<!-- gh-comment-id:3285683367 --> @annieappflowy commented on GitHub (Sep 12, 2025): > I see. What ways could this be implemented then? We write a flutter cal library
mirror commented 2026-03-23 20:44:27 +00:00
Author
Owner
Copy link

@Artemis1-0 commented on GitHub (Sep 13, 2025):

Yikes. I'll revisit this on the backburner.

<!-- gh-comment-id:3288711473 --> @Artemis1-0 commented on GitHub (Sep 13, 2025): Yikes. I'll revisit this on the backburner.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
copilot/fix-date-format-issue
feat/mention_a_person
merge_upstream_v6
mobile/release/0.9.3
release/0.9.3
release/0.9.2
select_source
release/0.9.1
refactor_import_data
release/0.8.9.1
release/0.8.9
anon_user_mode
release/0.8.8
fix_windows_selection
release/0.8.7
annieappflowy-patch-1
windows_local_ai
release/0.8.6
release/0.8.5
release/0.8.4
chore/optional-response-format
release/0.8.3
release/0.8.2
release/0.8.1
release/0.8.0
release/0.7.9
feat/support-rename-workspace
chat_rag_only
calculate_ui_test
release/0.7.8
release/0.7.7
stringfi_cells
hotfix/0.7.5
release/0.7.4
client-api-update
feat/collab-editing
fix_calculation_bug
feat/upload-file-in-document
update-client-api
feat/support-global-comment-on-web
update-client-api-2
feat/support-duplicate-publish-on-web
feat/ai-plan-billing
chore/test-web-deploy
chore/enable-billing-for-testing
build/test
ai_tag_feature
chore/enable-billing-plan
feat/billing-client-windows
chore/support-openai-chat
fix/try-no-media-kit
sign-in-error-format
workspace-invite-ci-test
last-workspace
workspace-invite-wip
feat/date-text-input
appflowy_v1
0.11.1
0.11.0
0.10.9
0.11.2
0.10.7
0.10.6
0.10.5
0.11.3
0.11.4
0.10.8
0.10.4
0.10.3
0.10.2
0.10.0
0.10.1
0.9.9
0.9.8
0.9.7
0.9.5
0.9.6
0.9.4
0.9.3
0.9.2
0.9.1
0.9.0
0.8.9
0.8.8
0.8.7
0.8.6
0.8.5
0.8.4
0.8.3
0.8.2
0.8.1
0.8.0
0.7.9
0.7.8
0.7.7
0.7.6
0.7.5
0.7.4
0.7.3
0.7.2
0.7.1
0.7.0
0.6.9
0.6.8
0.6.7.2
0.6.7.1
0.6.7
0.6.6
0.6.5
0.6.4
0.6.3
0.6.2
0.6.1
v0.6.1
0.6.0
0.5.9
0.5.8
0.5.7
0.5.6
0.5.5
0.5.4
0.5.3
0.5.2
0.5.1
0.5.0
0.4.9
0.4.8
0.4.7
0.4.6
0.4.5
0.4.4
0.4.3
0.4.2
0.4.1
0.4.0
0.3.9.1
0.3.9
0.3.8
0.3.7
0.3.6
0.3.5
0.3.4
0.3.3
0.3.2
0.3.1
0.3.0
0.2.9
0.2.8
0.2.7
0.2.6
0.2.5
0.2.4
0.2.3
0.2.2
0.2.1
0.2.0
0.1.6
0.1.5
0.1.4
0.1.3
0.1.2
0.1.1
0.1.0
0.0.9.1
0.0.9
0.0.8.1
0.0.8
0.0.7.1
0.0.7
0.0.6.2
0.0.6.1
0.0.6
0.0.6_beta.1
0.0.5.3
0.0.5.2
0.0.5.1
0.0.5
0.0.5_beta.2
0.0.5_beta.1
0.0.4
0.0.4_beta.3
0.0.4_beta.2
0.0.4_beta.1
0.0.3
0.0.3_beta.2
0.0.3_beta.1
0.0.2
0.0.1
Labels
Clear labels   
2024

   
2025

   
2026

   
acct mgmt

   
AI

   
automation

   
bug

   
calendar

   
ci

   
CJK

   
cloud

   
code-block

   
collaboration

   
copy-paste

   
database

   
data migration

   
data sync

   
deploy

   
desktop

   
develop

   
develop

   
documentation

   
duplicate

   
editor

   
editor-plugin

   
emoji

   
export

   
files

   
flutter-only

   
follow-up

   
formula

   
good first issue for devs

   
good first issue for experienced devs

   
grid

   
hacktoberfest

   
HACKTOBERFEST-ACCEPTED

   
help wanted

   
i18n

   
icons

   
images

   
importer

   
improvements

   
infra

   
install

   
integrations

   
IR

   
kanban board

   
login

   
look and joy

   
mentorship

   
mobile

   
mobile

   
needs design

   
new feature

   
new feature

   
non-coding

   
notes

   
notifications

   
onboarding

   
organization

   
P0+

   
permission

   
platform-linux

   
platform-mac

   
platform-windows

   
plugins

   
program

   
pull-request

Mirrored from GitHub Pull Request

  
Q1 25

   
Q1 26

   
Q2 24

   
Q2 25

   
Q3 24

   
Q3 25

   
Q4 24

   
Q4 25

   
react

   
regression

   
rust

   
rust

   
Rust-only

   
Rust-only

   
Rust-starter

   
Rust-starter

   
self-hosted

   
shortcuts

   
side panel

   
slash-menu

   
sync v2

   
table

   
tablet

   
task

   
tauri

   
templates

   
tests

   
themes

   
translation

   
v0.5.6

   
v0.5.8

   
v0.5.9

   
v0.6.0

   
v0.6.1

   
v0.6.4

   
v0.6.7

   
v0.6.8

   
v0.7.1

   
v0.7.4

   
v0.7.4

   
v0.7.5

   
v0.7.6

   
v0.7.7

   
v0.7.8

   
v0.8.0

   
v0.8.4

   
v0.8.5

   
v0.8.9

   
web
No labels
2024
2025
2026
acct mgmt
AI
automation
bug
calendar
ci
CJK
cloud
code-block
collaboration
copy-paste
database
data migration
data sync
deploy
desktop
develop
develop
documentation
duplicate
editor
editor-plugin
emoji
export
files
flutter-only
follow-up
formula
good first issue for devs
good first issue for experienced devs
grid
hacktoberfest
HACKTOBERFEST-ACCEPTED
help wanted
i18n
icons
images
importer
improvements
infra
install
integrations
IR
kanban board
login
look and joy
mentorship
mobile
mobile
needs design
new feature
new feature
non-coding
notes
notifications
onboarding
organization
P0+
permission
platform-linux
platform-mac
platform-windows
plugins
program
pull-request
Q1 25
Q1 26
Q2 24
Q2 25
Q3 24
Q3 25
Q4 24
Q4 25
react
regression
rust
rust
Rust-only
Rust-only
Rust-starter
Rust-starter
self-hosted
shortcuts
side panel
slash-menu
sync v2
table
tablet
task
tauri
templates
tests
themes
translation
v0.5.6
v0.5.8
v0.5.9
v0.6.0
v0.6.1
v0.6.4
v0.6.7
v0.6.8
v0.7.1
v0.7.4
v0.7.4
v0.7.5
v0.7.6
v0.7.7
v0.7.8
v0.8.0
v0.8.4
v0.8.5
v0.8.9
web
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
AppFlowy-IO/AppFlowy#1011
No description provided.