feat: remove namespaces, make projects infinitely nestable #1362

Merged
konrad merged 68 commits from feature/namespaces-be-gone into main 2023-05-24 14:14:03 +00:00
Owner

Depends on vikunja/api#1318

Frontend PR: vikunja/frontend#3323

Resolves vikunja/api#1501

Depends on https://kolaente.dev/vikunja/api/pulls/1318 Frontend PR: https://kolaente.dev/vikunja/frontend/pulls/3323 Resolves https://kolaente.dev/vikunja/api/issues/1501
konrad added 59 commits 2023-01-13 18:21:28 +00:00
continuous-integration/drone/pr Build was killed Details
5df54ddfb8
chore: generate swagger docs
continuous-integration/drone/pr Build is passing Details
01bd4ccf7a
fix(tasks): test
continuous-integration/drone/pr Build is passing Details
518bf7ded3
fix: lint errors
Member

make projects infinitely nestable

Nice!
How is that compatible with the tasks themselves?

> make projects infinitely nestable Nice! How is that compatible with the tasks themselves?
Author
Owner

Tasks still belong to one project, they are not affected by this change.

Tasks still belong to one project, they are not affected by this change.
Member

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.

> 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.
Author
Owner

Wouldn't this change mean that sublists should be displayed inside the projects in the list view separated by a headline.

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.

> Wouldn't this change mean that sublists should be displayed inside the projects in the list view separated by a headline. 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.
Member

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.

> 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.
konrad force-pushed feature/namespaces-be-gone from 518bf7ded3 to 442627be62 2023-03-14 14:25:02 +00:00 Compare
konrad force-pushed feature/namespaces-be-gone from 50185b846a to a7c2ca146c 2023-03-14 16:43:12 +00:00 Compare
konrad added 1 commit 2023-03-14 16:44:02 +00:00
continuous-integration/drone/pr Build is passing Details
1c07bce373
fix: rename project receiver variable
konrad force-pushed feature/namespaces-be-gone from 1c07bce373 to fb1898f8b8 2023-03-24 18:18:53 +00:00 Compare
Member

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:

  • Will there be multiple root projects or is there one root project per user—basically the user project?
  • Do we allow root level project(s) (the current namespaces) to have tasks as direct children in the short term? What about in the long term?
  • Can second level projects (the current projects) contain direct child tasks if they contain child projects? Or should this be exclusive, similar to IMAP folders?
  • What projects should users be able to share?

My current opinion is the following:

  • Root projects should not be able to contain tasks as children.
  • I'm inclined to the view that we shouldn't allow project to contain direct child tasks if they contain child projects—at least I would not indicate in the UI that this is possible. Instead I think the UI should do the following:
    • In the moment the user creates a sub project inside a project the existing tasks of the projects should be seen as meta tasks of the projects. For example project managing tasks that are about managing the tasks inside the sub project folder.
    • The consequence would be that if we open a project that contains a sub project we don't show direct child tasks directly anymore. Instead we show a list of sub projects. So if the mentioned parent project now has one user created sub project and has some user tasks from before we should display this as as two projects. The project meta project (this could always have the same name) and the actual user created project.
    • In conclusion every new project already starts with one meta project about itself that we don't show as long as there is not other sub project.
      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.
  • Only allow root projects to be shared.
  • If a parent of a project is shared, the user shouldn't be able to share a child project again. In the UI we could make it clear that the project is shared by a parent and link to its sharing settings.
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: - Will there be multiple root projects or is there one root project per user—basically the user project? - Do we allow root level project(s) (the current namespaces) to have tasks as direct children in the short term? What about in the long term? - Can second level projects (the current projects) contain direct child tasks **if** they contain child projects? Or should this be exclusive, similar to IMAP folders? - What projects should users be able to share? My current opinion is the following: - Root projects should not be able to contain tasks as children. - I'm inclined to the view that we shouldn't allow project to contain direct child tasks if they contain child projects—at least I would not indicate in the UI that this is possible. Instead I think the UI should do the following: - In the moment the user creates a sub project inside a project the existing tasks of the projects should be seen as *meta* tasks of the projects. For example project managing tasks that are about managing the tasks inside the sub project folder. - The consequence would be that if we open a project that contains a sub project we don't show direct child tasks directly anymore. Instead we show a list of sub projects. So if the mentioned parent project now has *one user created sub project* and has *some user tasks from before* we should display this as as two projects. The project meta project (this could always have the same name) and the actual user created project. - In conclusion every new project already starts with one *meta project about itself* that we don't show as long as there is not other sub project. 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. - Only allow root projects to be shared. - If a parent of a project is shared, the user shouldn't be able to share a child project again. In the UI we could make it clear that the project is shared by a parent and link to its sharing settings.
Author
Owner

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.

That's correct.

Will there be multiple root projects or is there one root project per user—basically the user project?

A user can create as many root projects as they like.

Do we allow root level project(s) (the current namespaces) to have tasks as direct children in the short term? What about in the long term?

Yes. That's already the case right now with the changes in this PR.

Can second level projects (the current projects) contain direct child tasks if they contain child projects? Or should this be exclusive, similar to IMAP folders?

Yes. They are real projects, not like folders. If they were just folders, we'd have namespaces all over again, but more complicated.

What projects should users be able to share?

All projects. There's no distinction made whether a project has subprojects.

Really the only difference is this:

  • Projects are now nestable
  • Namespaces are gone
  • There's a migration which creates a new project and structure for each old namespace. That's done mostly so that the structure for current users is similar. New users won't get a new namespace, only a default "Inbox" project (This solves the "I just want to create some tasks and don't care about namespaces or projects" problem).

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'm inclined to the view that we shouldn't allow project to contain direct child tasks if they contain child projects—at least I would not indicate in the UI that this is possible.

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.

> 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. That's correct. > Will there be multiple root projects or is there one root project per user—basically the user project? A user can create as many root projects as they like. > Do we allow root level project(s) (the current namespaces) to have tasks as direct children in the short term? What about in the long term? Yes. That's already the case right now with the changes in this PR. > Can second level projects (the current projects) contain direct child tasks if they contain child projects? Or should this be exclusive, similar to IMAP folders? Yes. They are real projects, not like folders. If they were just folders, we'd have namespaces all over again, but more complicated. > What projects should users be able to share? All projects. There's no distinction made whether a project has subprojects. Really the only difference is this: * Projects are now nestable * Namespaces are gone * There's a migration which creates a new project and structure for each old namespace. That's done mostly so that the structure for current users is similar. New users won't get a new namespace, only a default "Inbox" project (This solves the "I just want to create some tasks and don't care about namespaces or projects" problem). 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'm inclined to the view that we shouldn't allow project to contain direct child tasks if they contain child projects—at least I would not indicate in the UI that this is possible. 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.
konrad changed title from WIP: feat: remove namespaces, make projects infinitely nestable to feat: remove namespaces, make projects infinitely nestable 2023-03-27 20:14:33 +00:00
Member

Do we allow root level project(s) (the current namespaces) to have tasks as direct children in the short term? What about in the long term?

Yes. That's already the case right now with the changes in this PR.

👍

Can second level projects (the current projects) contain direct child tasks if they contain child projects? Or should this be exclusive, similar to IMAP folders?

Yes. They are real projects, not like folders. If they were just folders, we'd have namespaces all over again, but more complicated.

What projects should users be able to share?

All projects. There's no distinction made whether a project has subprojects.

Really the only difference is this:

  • Projects are now nestable
  • Namespaces are gone
  • There's a migration which creates a new project and structure for each old namespace. That's done mostly so that the structure for current users is similar. New users won't get a new namespace, only a default "Inbox" project (This solves the "I just want to create some tasks and don't care about namespaces or projects" problem).

Yes that makes totally sense structurally!

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.

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.

I'm inclined to the view that we shouldn't allow project to contain direct child tasks if they contain child projects—at least I would not indicate in the UI that this is possible.

I feel like this sounds like namespaces, but more complicated. There would be two kinds of projects, ones with tasks and ones without.

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.

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.

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'.

> > Do we allow root level project(s) (the current namespaces) to have tasks as direct children in the short term? What about in the long term? > > Yes. That's already the case right now with the changes in this PR. 👍 > > Can second level projects (the current projects) contain direct child tasks if they contain child projects? Or should this be exclusive, similar to IMAP folders? > > Yes. They are real projects, not like folders. If they were just folders, we'd have namespaces all over again, but more complicated. > > > What projects should users be able to share? > > All projects. There's no distinction made whether a project has subprojects. > > Really the only difference is this: > > * Projects are now nestable > * Namespaces are gone > * There's a migration which creates a new project and structure for each old namespace. That's done mostly so that the structure for current users is similar. New users won't get a new namespace, only a default "Inbox" project (This solves the "I just want to create some tasks and don't care about namespaces or projects" problem). Yes that makes totally sense structurally! > 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. 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. > > I'm inclined to the view that we shouldn't allow project to contain direct child tasks if they contain child projects—at least I would not indicate in the UI that this is possible. > > I feel like this sounds like namespaces, but more complicated. There would be two kinds of projects, ones with tasks and ones without. 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. > 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. 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'.
Author
Owner

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.

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.

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.

Right now we only show it in the sidebar and in the overview.

And if currently the gantt view is enabled will the sub projects be listed at the top or at them bottom?

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.

> 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. 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. > 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. Right now we only show it in the sidebar and in the overview. > And if currently the gantt view is enabled will the sub projects be listed at the top or at them bottom? 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.
konrad force-pushed feature/namespaces-be-gone from 5640ce439e to a4218c0c5b 2023-04-01 10:57:00 +00:00 Compare
konrad force-pushed feature/namespaces-be-gone from fb4ca42e11 to 1625b81267 2023-04-02 16:34:57 +00:00 Compare
konrad force-pushed feature/namespaces-be-gone from 1625b81267 to cbfbaf4799 2023-04-02 16:56:02 +00:00 Compare
Author
Owner

I've deployed the changes of this PR to https://projects.vikunja.dev/api/v1/ to test it more easily.

I've deployed the changes of this PR to https://projects.vikunja.dev/api/v1/ to test it more easily.
konrad force-pushed feature/namespaces-be-gone from 9db2bbd5aa to 4a51336274 2023-04-10 15:43:29 +00:00 Compare
konrad force-pushed feature/namespaces-be-gone from 4a51336274 to be5faf6a81 2023-04-18 10:23:25 +00:00 Compare
konrad force-pushed feature/namespaces-be-gone from be5faf6a81 to e5dde315fb 2023-05-24 13:53:37 +00:00 Compare
konrad merged commit 82beb3bf67 into main 2023-05-24 14:14:03 +00:00
konrad deleted branch feature/namespaces-be-gone 2023-05-24 14:14:03 +00:00
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
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: vikunja/vikunja#1362
No description provided.