I’m drafting a schema to handle general tasks, long-term, intermittent projects, and knowledge/ideas. I thought I might make some sort of structure like shown, with subtasks made via a self-referencing a relation field.
I can drag & drop tasks/subtasks between items in the list view (using recursive organization grouping), but how would you move a task to another database or space?
It is unclear what databases you want to have so far. For example, you have two projects, are these projects will contain same Task database?
I’m not sure the best way to set it up, and I’m still very new to using Fibery.
I was thinking separate task databases, and projects large enough could get it’s own database or space, but I’m not sure if that’s feasible.
I’d suggest a Project database, linked (1:m) to a Task database, and then add a Category select field to your Project db to distinguish between Education and Construction projects, say.
Project db can have a 1:m self-relation (so that X House Layout/Design project can be parent to Dining Room, Kitchen, Living Room sub-projects (all in the Construction category).
And you can have a 1:m self-relation for the Task db so that Tasks can have Sub-tasks and Sub-sub-tasks etc.
Meanwhile, you can have two Projects on the Education category: ‘IT applications’ and ‘Applied stats’.
I like this, I could also use a tags DB or second category if it gets large enough. The only potential issue I see on its face is the number of fields getting unwieldy since different projects will likely need different fields. I believe some of the Fibery documentation warns about performance issues doing that.
This is only tangentially related, but is it possible to display single or multi-select fields or something similar as buttons or checkboxes vs. drop-downs? My process sorts through a few different options/categorizations for tasks, filtering them from the view when all the required fields are filled. The best way to do this quickly that I’ve found so far is to use a bunch of checkboxes along with a kanban-view.
Other types of fields would serve the purposes better, but since multi-select requires more clicks and scrolling it’s much slower when sorting a lot items.
