feat: remove namespaces, make projects infinitely nestable #1362
No reviewers
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#1362
Loading…
Reference in New Issue
No description provided.
Delete Branch "feature/namespaces-be-gone"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Depends on vikunja/api#1318
Frontend PR: vikunja/frontend#3323
Resolves vikunja/api#1501
Nice!
How is that compatible with the tasks themselves?
Tasks still belong to one project, they are not affected by this change.
I meant this more conceptually. For example:
Wouldn't this change mean that sublists should be displayed inside the projects in the list view separated by a headline.
Because if the list is collapsed the only indication that there are sub entries would be an arrao before I guess.
That's something I thought about but decided to not do right now because it add a lot more in complexity to this already huge PR. It also opens up new problems for things like Kanban buckets and filtering.
Ohh it's absolutely something new.
For now I wouldn't show the sublists in kanban view. Thinking further I think buckets and sublists should be unified. Or are there good reasons not to do this. AFAIK this is what Notion, Todoist and Tana does.
I didn't think of the filtering though. Good point! Maybe the filter would be applied to each of the lists themselves. Still opens a lot of new questions that are obviously not part of this PR anymore. We should still have a clear vision of what that means for us.
518bf7ded3
to442627be62
50185b846a
toa7c2ca146c
1c07bce373
tofb1898f8b8
I've another question / request regarding what this PR implements:
Could we disable the generation of sub lists inside the second level lists on an api level until we have a clear concept how to implement this in the frontend.
What I mean is: As far as I understood the namespaces will be gone after the merge of this PR. This means that former namespaces will also be projects that will contain one level of sub-projects if applied on the old hierarchy. The question that immediately arises for me is:
My current opinion is the following:
I hope that this is understandable. If not I could make some simple wireframes that should make this easier to understand.
The question that emerges for me about the API layer is if the meta project would be a real new database entry that gets created as a side effect in the moment that the user creates a sub project of an existing project. Or if this visual representation in the ui doesn't have a consequence on the data modeling layer.
That's correct.
A user can create as many root projects as they like.
Yes. That's already the case right now with the changes in this PR.
Yes. They are real projects, not like folders. If they were just folders, we'd have namespaces all over again, but more complicated.
All projects. There's no distinction made whether a project has subprojects.
Really the only difference is this:
My goal with this change is to make the concept more simple for users with only a handful of projects but keep it flexible enough for more complicated setups and users with many projects.
I feel like this sounds like namespaces, but more complicated. There would be two kinds of projects, ones with tasks and ones without.
There are use-cases for a hierarchy of subprojects within a project with tasks at each level. For example, having a project on top and subprojects for specific aspects of that projects. There will probably still be tasks which won't fit in any of the subprojects and are therefore created in the root project.
WIP: feat: remove namespaces, make projects infinitely nestableto feat: remove namespaces, make projects infinitely nestable👍
Yes that makes totally sense structurally!
From working with Notion I know that making it possible to have different share setting for sub items makes stuff really hard. They introduces special restrictions (see: https://www.notion.so/help/intro-to-teamspaces under the headline "How to restrict, expand & restore sub-page permissions"). Before they added that feature I encountered a lot of misconfigurations. Even with them very often stuff got publicly shared / shared with a third party which they should not have access to.
Regarding
There would be two kinds of projects, ones with tasks and ones without.
:I saw my proposal more as a different kind of view that gets only activated when a project has sub projects. I forgot to mention why I think that's necessary:
In the moment a project has a sub project the question immediately arised how and where we display that sub project. Do we show it in the sidebar. Do we show it in the main view. And if currently the gantt view is enabled will the sub projects be listed at the top or at them bottom? Let's say we decide to show them in the top or bottom: What happens if we select multiple tasks in the future if we add a multiselect feature. We would immediately get space problems on mobile which will lead to bad UX.
Basically I want to prevent having stuff like the gantt chart (for the direct child tasks) AND a 'folder' structure navigation for the sub projects. So it's all about making it clear to the user where he currently is.
I think it should be shown similar to files and folders. What I basically meant with the meta subproject is that the files in a folder should be grouped together, while the folders should be grouped as well. This means for Vikunja we show the gantt view / list view etc normally for the direct child tasks of a project.
Absolutely! And this can and should still happen!
"for specific aspects of that projects" => this is exactly what I meant by meta project. And if you name your project corectly this should always be the case. Because you would (or at least should) only put a task inside a project if it has something to do with it => hence 'meta'.
You mean cases where a project was shared read-only, and the user now shares a subproject of that with write permissions? That would not be possible with the changes in this PR. Users need to have "admin" permissions (either have created that project or got it shared with admin permissions) to share a project. And permissions bubble down, so they would need admin permissions on the parent project that was originally shared with them.
Right now we only show it in the sidebar and in the overview.
The Gantt view will not show any tasks or projects other than the current project. We might consider this in the future, but given the complexity I'd like to not do that in this PR.
5640ce439e
toa4218c0c5b
fb4ca42e11
to1625b81267
1625b81267
tocbfbaf4799
I've deployed the changes of this PR to https://projects.vikunja.dev/api/v1/ to test it more easily.
9db2bbd5aa
to4a51336274
4a51336274
tobe5faf6a81
be5faf6a81
toe5dde315fb