The last context we need: people !

[bepolymathe]

Hi @callumalpass

I'm really grateful for Tasknotes. It's a great tool! Thank you.

Now that we have the context, the tags and the projects... it seems to me that there is only one thing missing for complete project management: people

Of course, if I want to assign a task to someone I could use the #John tag function but I find that what you developed for projects is more useful on a daily basis... because it allows you to have active links to a file directly from task view. Why not add the same thing for people with a people: property allowing a link to a file as a value. Many people have files by person or author in Obsidian and this would allow us to quickly navigate to them while seeing them in our tasks. With the same filter system as for projects it would be very powerful...

I don't know if I'm the only one who thinks this is a cool idea?

[jpmoo]

Very cool idea, but would suggest "delegates" as the term. In my vault, I have notes to represent people, but I also have notes representing organizations/groups/etc. I just as often delegate tasks to a group/organization/etc. (e.g., [[Accounting]]) as to a person (e.g., [[John the Accountant]]).

Also, multiple delegates. So ...

delegates:

• [[Accounting]]
• [[Mr. My Assistant]]
• etc.

[edakimling]

Great Idea. But there is a pattern now. For one group of people, they will want links to 'people' on top of 'projects', other folks will want links to something else...

So why not just make it a custom 'lookup' field. So you can add a lookup to any folder, for a pattern and do this for many fields. Basically take the logic for projects and make it a custom thing. Cheers

[renatomen]

Hi @bepolymathe , @jpmoo and @edakimling ,

I'm one of the plugin contributors and I've implemented custom properties a few months ago to address those use cases.

Please check my replies to the issues below with solutions to use cases very close to what you're suggesting:

• [FR]: add participants to tasks
• [FR]: Display custom properties in tasknote card and widget

One of the core philosophies of the Plugin is to avoid making assumptions about users' workflows.

TaskNotes allows you to achieve all the suggestions above by configuring custom properties of any type and choosing which name to display in TaskNotes. This way, TaskNotes doesn't "enforce" a naming convention and allows users to choose what's meaningful to them. You can assign to people, participants, owners, reporters, organisations, teams and whatever makes sense in your workflow.

In my workflow, people are represented using three different properties:
Owner: Owns the the task/project. Can be a person, a team, an organisation, a task link or a simple text. It is the entity accountable for the task outcome, not necessarily the entity working on the task.

Assignee: The person actively working on the task. E.g. Chuck may be the owner, but the task is allocated to Bruce for review.

Reporter: Is the person who requested the tasks. E.g. @bepolymathe is the requester of this task. CallumAlpass may be the owner because he maintains the plugin, but I'm the assignee because I'm implementing the feature.

This will be different for everyone. Hence, I implemented the custom features so the user decides and the Plugin stays clean.

[renatomen]

Hi @edakimling,

(sorry if you see New Zealand English mixed with American English, depending on my mood and energy levels, I mix them up 😄)

Why were projects implemented separately with their own settings?

The original developer @callumalpass built the projects feature before I came on board. From what I've seen in past discussions, it was designed to handle hierarchical parent-child relationships between action items.

Here's the key: whilst the field is called "project", it actually functions as a parent relationship. This may be confusing to some people because the name "project" means different things for different users – your "project" might be someone else's "parent" or "area", "goal", "initiative", etc.

TaskNotes needs to know which property stores this parent relationship to make several core features work:

• Nesting tasks under other tasks
• Counting how many subtasks a task has
• Other hierarchical behaviours (Like showing the mini folders to drill down to project)

What's great about how @callumalpass implemented it is that it lets you map this to any property name you want – no forced naming conventions. (In my vault, I use "In" for this relationship, e.g. [[Task A]] in [[Project B]]. So in my settings, Project = In.)

Later, I added the ability to map and filter by other fields like assignee, value, etc., plus grouping and subgrouping capabilities. But those grouping/subgrouping capabilities are just visual hierarchy. Not structural hierarchy between entities.

Why not just use a custom field with type list?

Because an enumeration (dropdown list) is necessary but not sufficient.

Projects need special handling because TaskNotes relies on them for hierarchical calculations. Other fields are just dropdowns – they don't drive any structural behaviours in the system.

Let me know if this helps.
And feel free to challenge anything I said. I'm just another user and this is what the plugin discussion forums are for.
Cheers

[renatomen]

Hi @bepolymathe ,

I submitted a Pull Request (#908) with the fix for the bug (#905 ) you reported and another behaviour I discovered when testing. The project auto-suggestions from Task Creation and Task Edition modals were inconsistent #907. Task Edition was not respecting the hierarchical tags, tag tag exclusion syntax etc.

The original developer still needs to review it, merge it to include in the next release. There's always a chance that my fix won't be accepted.

[edakimling]

Thank you for this fruitful explanation. I appreciate the time and thought you put into your replies.
I am new to TaskNotes, so I will take what you wrote and experiment with it. There are bunch of bugs I found already in the past few days, and I am converting form the Tasks plugin (one file with all tasks). I will post the bugs I found within next few days, provided they were not already posted. I'll check first.

Thank you for your contributions and for prompt replies. This plugin is golden and much needed for obsidian

[renatomen]

@bepolymathe , my fixes were accepted and included in the next release.

[bepolymathe]

Thank you very much for your responsiveness. Great!