Project Support ?

[hokfujow]

Hi - Apologies if this has been covered but nothing obvious came up in my search. Many of my tasks are project based. I have a series of notes that represent information about the project. These might contain the names of stakeholders, related systems, etc. These files have a Type property with value "Project", and a project property with value "True". When I create notes daily (often meeting notes, agendas, logging of work in progress, etc), I give these notes a property called project. The value is not a string but rather a link to the corresponding project file, eg Project: [[Project1]].
To be honest, this came about because I had imported from Capacities, which used an object based system, so Projects were objects with a particular set of properties. I'm not sure this was the best way to handle things in Obsidian, but up until now it's been working okay.

When I create tasks in a file that has that Project property link, I'd like the tasks to automatically be linked to that project. (I could of course add a tag to each task, but I'd prefer not to have that kind of redundancy).
Task Genius seemed ideal for me as it supports identifying projects via path or metadata. As you noted elsewhere, TG is full of great features. Unfortunately, it seems to be pretty buggy and seems to get confused by the value of the project property being a link rather than a string. Perhaps this is inherent in the underlying Tasks plugin though or in Obsidian's way of handling properties.

I couldn't find a way in Task Board to explicitly add a way to group tasks via the project property. It seems I could do it by adding tags corresponding to projects, but as I said, I'm trying to avoid having redundant project schemes. That seems like a recipe for bad data.

Is there something I've missed in TB that would allow me to do this? If not, do you see that on your roadmap in the near-ish future?

Thanks so much.

Michael

[byq77]

If I remember correctly, TG would automatically add the tag #project/project_name to all your tasks when you use the project metadata key anyway. Last time I checked it, it was also bugged (it was adding the tag twice).

I manually tag all tasks for a project with the #project/project_name tag, and find it the best approach. It is shared by all TB, TG, and Tasks extensions, and probably many other TODO plugins. If you think about it, having a separate metadata key only for projects is redundant when Obsidian already has a built-in tag system. The TG extension suffers from having too many options and being too complex.

[hokfujow]

Yes, I've been seeing TG keep replicating the project multiple times as well. Thanks for the response. Not quite what I was looking for but I get the thinking.

[tu2-atmanand]

I might not have exactly understood this workflow,but there are few things on roadmap which I think might be related and might help in your workflow.

As we see, today, Obsidian users have their own custom workflows. Most of these workflow are mostly managed using properties. For inline-tasks we can create custom properties using Dataview plugin like syntax and for task-notes we have frontmatter (also known as metadata) provided by Obsidian in-built. So, I have thought of building mechanism in Task Board such that, users can define their own custom properties and use these properties to manage their tasks more effortlessly.

Ofcourse, we have a the tags itself to do these. Such that using nested tags we have define any kind of property to the task, for example, #property/value. But, I have got various requests, where users don't want to make use of the tags for this functionality. Hence the only option remaining is to use custom properties.

For this new mechanism, I have already created a ticket: #688.

With this new feature, it will help Task Board to avoid integrating all these different workflows in-built and give this power to users to manage on their own.

This new mechanism will also going to open a lot of new possibilities. For example, as mentioned in the original post by OP. If there are inline tasks inside a normal note with the specific property in its frontmatter, then all the inline-tasks within that note will automatically get that property. This property can be 'project', 'area', 'subject', etc.

Also, after the implementation of this property, a new type of column can also be introduced. Where, if user drags and drops a task from one column to another, the previous frontmatter key/value will update accordingly. But, ofcourse this is only possible for task-notes and not inline tasks.

So, in summary, at present the project property is not supported by TaskBoard. But with this new mechanism, it should be easily possible. And I can't promise, when I'll be implementing this, but this is one of the important feature on roadmap right now.

[hokfujow]

Thanks! That does sound like what I'm looking for. Not sure if I'm going to adopt TN yet as I prefer to be able to use the existing Tasks plugin and keep my tasks within notes rather than moving them to separate notes for each task. But I'm still evaluating which approach works better for me.

[quake1508]

Concrete use case: TaskForge @context / +project compatibility

I'm using TaskForge (Android/iOS) as a mobile companion alongside Task Board on desktop. TaskForge uses @context and +project as distinct metadata types within inline tasks (standard Obsidian Tasks format), e.g.:

- [ ] Update Mealie BASE_URL #Server #Traefik @computer +Server-Homelab ⏬
- [ ] 3D print robot ramp with magnets #3D @printer +3D-Printing
- [ ] 

Task Board currently only parses #tags (via hashTagsRegex in VaultScanner.ts), but completely ignores @ and + prefixes — so these metadata dimensions are invisible on the board.

Interestingly, significant groundwork for this already exists in the codebase:

• BoardConfigs.ts: "project" and "context" are already defined in the columnSortingCriteria union type
• • ColumnSortingAlgorithm.ts: Stubs returning "" with comments // Project is not yet implemented in taskItem and // Context is not yet implemented in taskItem
• • ViewTaskFilter.ts: A fully implemented filter case for "project" (contains, doesNotContain, is, isNot, startsWith, endsWith, isEmpty, isNotEmpty) — only the dropdown option is commented out: // project: t("project")
• • ConfigureColumnSortingModal.ts: // .addOption("project", t("project")) // Will be implemented in future
    What's missing to complete this:

1. Regex patterns for @word and +word in VaultScanner.ts (analogous to hashTagsRegex)
2. 2. projects: string[] and contexts: string[] fields in the taskItem interface
3. 3. New colTypeNames (e.g. namedProject, namedContext) in ColumnSegregator.ts
4. 4. Uncommenting the existing UI elements
      This would enable a seamless desktop/mobile workflow: TaskForge handles @/+ natively on mobile, Task Board handles them on desktop. Both read/write the same markdown files.

Would love to see this covered by #688 — happy to help test or contribute if useful!

[tu2-atmanand]

Hi @quake1508 !

Looks like you have already got the ticket #688 . For inline-tasks we have #414 .

Actually, every other plugin and service will keep using their own formats. For task-notes its easy because we have frontmatter/properties and these frontmatter is supported by Obsidian officially.

But for inline-tasks there are no such official specifications/formats. So every developer is creating their own formats. And its very difficult to integrate each and every format. Since in the future more and more plugins/apps will be developed.

The famous formats we know for inline-tasks are Dataview formats. For example, like this :

• [project:: computer ]
• [context:: Server-Homelab]

These formats are much versatile and used by a lot of users. So Task Board will be adopting these formats as the default ones and there is no official plan to support the formats like @project or +context. To allow users to have any kind of property to their inline-tasks just like frontmatter, I have decided to go with the Dataview formats.

I believe, all the other plugins/apps should adhere to the formats used by most of the users of Obsidian.