[Idea] Using subpaths for new boards

[mms-gianni]

First of all, congratulations on your work. I had a closer look into it.

Opening the task board with a random path string loads the board but it does not work.

Example: http://localhost:8080/randomString

This is strange but not a big issue. But this led me to this idea: it would be nice to have a new and clean board on any subpath to manage multiple boards for teams and/or projects

http://localhost:8080/team1
http://localhost:8080/team2
http://localhost:8080/projectX
http://localhost:8080/projectY

PS: I was not able the set labels for this issue.
PPS: Why did you use nginx to run the application and not node itself?

[BaldissaraMatheus]

Hey, thank you for reporting the issue and for the suggestion.

I was testing everything up again a few hours ago and it seems like that both the subpath and title env variables are not working as expected, I think it may have broken with the changes in the Dockerfile released earlier, but I still need to invesitgate it further.

About your suggestion, it kinda works this way right now if you use a different port for each project (well, at least it was when the subpath variable was working). The application was designed to contain a single project for container, so each one of them have its own port, title and volumes (for styles and files), in such way that each project is self contained. If having a different port is an issue for you, you could "hide" it by using a local dns or reverse proxy.

We could think in way for the application to handle multiple projects by mapping a project to its subpath, but the biggest challenge would be find a way to organize the files without overcomplicating it too much. Right now each lane/list is a folder and each card is a file, in a way that is very easy to navigate and to understand just by looking into it, so I'd really like to avoid compromising it.

About using nginx instead of node: I was thinking in making the application SSR, but to be honest I don't have much experience with it, so I decided to make it a SPA so I could develop it faster and maybe convert it to SSR in the future, it would probably simplify the docker setup a lot

[mms-gianni]

The simples way, and maybe the most secure and atomic, would be to add an addition layer to the structure:

So what we have now :

files
├── backlog
├── done
│   └── doit.md
└── progress

To

files
├── project1
│   ├── backlog
│   ├── done
│   │   └── doit.md
│   └── progress
└── project2
    ├── backlog
    ├── done
    │   └── doit.md
    └── progress

[accforgithubtest]

Does tasks.md now support multiple projects using the above folder structure ?

[BaldissaraMatheus]

Does tasks.md now support multiple projects using the above folder structure ?

No, right now we don't support the above structure. In order to have multiple board you have to deploy different containers for each one of them. If you're running the application from the source code you have to change the ports so they don't conflict

[benjaminapetersen]

I'd love to hop on this as a big WIN for me as well!
I just commented on the - [ ] sibling issue. The productivity provided by making /boards and - [ ] subtasks would really be fantastic. 🥳

[benjaminapetersen]

Fond of the suggested structure above:

projects
├── project1
│   ├── backlog
│   ├── done
│   │   └── doit.md
│   └── progress
└── project2
    ├── backlog
    ├── done
    │   └── doit.md
    └── progress

via existing flags, no change needed

  -v $PWD/projects/:/tasks/ \
  -v $PWD/config/:/config/ \

And then subdirectories contain same things they contain today, but with 1 layer between for projects. 🥳

[benjaminapetersen]

To be honest, I'm not sure if a directory structure update is really in order for this. In fact, it could be detrimental.
Essentially, projects is just tags but for one purpose.
So it would be easier to keep as is, perhaps have a "project" drop down (just like tags), but also be able to null it out and see everything. And if a task belongs to multiple projects... its just tags again.
A /url/path would be handy, conceptually, but other than that, not sure a backend rework would be needed at all.

Is the uber-simplest short term workaround just tags with project:foo prefix? Perhaps.

[BaldissaraMatheus]

To be honest, I'm not sure if a directory structure update is really in order for this. In fact, it could be detrimental. Essentially, projects is just tags but for one purpose. So it would be easier to keep as is, perhaps have a "project" drop down (just like tags), but also be able to null it out and see everything. And if a task belongs to multiple projects... its just tags again. A /url/path would be handy, conceptually, but other than that, not sure a backend rework would be needed at all.

Is the uber-simplest short term workaround just tags with project:foo prefix? Perhaps.

I think the downside of this approach (if I understood correctly) is that all projects would share the same lanes, since the directory structure would be kept the same

[BaldissaraMatheus]

I was thinking about the possibility to use directories as both lanes and projects. So every lane could be opened as a project, with their own subpath.

So let's say we have the following directory structure:

/root-dir
- /lane-1
- - task-1.md
- /lane-2
- - task-2.md
- - /todo
- - - task-3.md
- - /doing

opening / in the browser would show the board containing lanes lane-1 and lane-2, with the files task-1.md and task-2.md, and would not show their sub directories at all. Like this:

Then by opening /lane-2 in the browser, the board would reflect what is within lane-2 directory, containing lanes todo and doing, and would not show task-2.md file. Like this:

I think this approach have the following benefits:

• The user is able to easily create an unlimited tree of projects and subprojects;
• It's easy to navigate, and pretty much mirrors the navigation behavior of a file manager. Also conveniently fits Idea: Link to open a specific note on fullscreen #88 perfectly;
• We can keep the file/directory structure the same as it is today

It has an obvious downside, though. The user may not want a project to be seem as a lane. For example, given a user has a root folder structured as

/todo
/doing
/project-1
/project-2

and they want every directory to be their own thing, it would be annoying to have it project-1 and project-2 visible like this.

To handle this problem I think we could add a flag/chip/whatever to tag as project all directories that have sub directories inside them (in the first example lane-2 would have this flag, and lane-1 would not), and add a filter option to hide all project lanes.

What you guys think?

[benjaminapetersen]

The interesting thing about this project is its ability to support 2 fundamentally different approaches:

1. The Web UI visual board (of course)
2. The markdown files on the filesystem

I'm curious if the vision is clearly defined to make the most of both. One thing that really drew me was the ability to edit a card in both views (though not the case today as the web app does not reload from disk). Second, the visual of the webapp in a Kanban style board is great. Third, cards on the file system I can commit to a git repo is fantastic. Intuitively navigating the cards on file system with an editor like VSCode,Atom,Sublime,etc is really useful.

So, to a degree, I would think any file system changes made should suppor the second use case of navigation of tasks via an external tool. Deciding if project is merely a UI construct (like tags currently) as metadata attached to the Mardown files, or if it is also a filesystem change is a pretty interesting question. I think it is probably true that it affects both vectors.

Concerns then:

1. If lane-1 exists in 2 projects, but cards on filesystem live under lane-1 file path, but are mingled between 2 (or 3,4,5) projects, this would be a detrement to the file browsing use case.
2. If you lose the file browsing via editor use case... then a lot of the value gained from Mardown files is likely lost.

So I would tend to think either:

1. /project-foo ought nest its own lanes /lane-1, even if the lane is replicated across projects, or
2. project as a concept remain a UI only feature like tag, and keep the file system as lanes only
   • I think this is more ideal for UI dev, but less ideal for long term value. Once a few hundred files exist on the file system, navigating the files to make sense of things would be a chore.

[benjaminapetersen]

Another concern here will be file duplicates.

• /project-A/lane-X/file-foo.md
• /project-B/lane-X/file-foo.md

If there are collapsed, then file-foo.md will have 2 entries in the file system, requiring disambiguation. UUID suffix could work, but might be a bummer of a UX.

[benjaminapetersen]

From the standpoint of Editing via filesystem alongside the Web UI, this does maintain an intuitive structure:

tree # two projects clearly exist
.
├── big-project
│   ├── archive
│   │   ├── idea-for-new-thing-1.md
│   │   └── idea-for-new-thing-2.md
│   ├── backlog
│   │   ├── doc-feature-A.md
│   │   └── doc-feature-B.md
│   ├── done
│   │   └── feature-A.md
│   └── in-progress
│       ├── feature-B.md
│       └── minor-fix-for-thing.md
└── medium-project
    ├── backlog
    │   ├── feature-C.md
    │   ├── feature-D.md
    │   └── feature-E.md
    ├── done
    │   ├── feature-F.md
    │   └── thing.md
    └── icebox
        ├── feature-A.md
        ├── idea-X.md
        └── task-2.md

But if /project dirs go away, it gets tough to maintain context:

tree # hard to see that 2 projects exist
.
├── archive
│   ├── idea-for-new-thing-1.md
│   └── idea-for-new-thing-2.md
├── backlog
│   ├── doc-feature-A.md
│   ├── doc-feature-B.md
│   ├── feature-C.md
│   ├── feature-D.md
│   └── feature-E.md
├── done
│   ├── feature-A.md
│   ├── feature-F.md
│   └── thing.md
├── icebox
│   ├── feature-A.md
│   ├── idea-X.md
│   └── task-2.md
│   └── task-2.md # aw snap! this would be a collision, requiring task-2-{UID1}.md and task-2-{UID2}.md
└── in-progress
    ├── feature-B.md
    └── minor-fix-for-thing.md

A feature to Archive a whole project (that is done) is fairly intuitive if it just means to ignore the directory in UI.