Allow editing Dataview projects

[danieltomasz]

What would you like to be added?

I would like the plugin to support the :: property metadata defined outside yaml of the file (the same way as the are supported in the dataview plugin (while the priority/importance should be put on yaml)

Why is this needed?

In many notes I have metadata defined outside yaml , also metadata outside yaml gives more flexibility for user to work with othe rplugins, for example tags:: #example will be picked by "colorful tags" plugin and example might be have applied colour

[marcusolsson]

Inline attributes (::) are already supported in projects using Dataview queries. Since it's a Dataview feature however, you need the Dataview plugin enabled. Would that work for you?

[wimlep]

It works for display, but the attributes are not shown in as editable fields

[danieltomasz]

In my request I meant also support for for inline properties in the files in the path (folder) based projects

I wouldn't say that this is only a Dataview feature (although brought to popularity by this plugin), it is rather a different way of specifying properties (metadata) that is not limited to yaml (although it is not standardised in Obsidian in the same way as metadata in yaml ) and could be defined in the body of the text

As currently there is some work on the Obsidian developers side on improving metadata [1] (inspired or not by tana "supertag rush"), I think this feature might wait until there will be stable API or at least known what new change are introduced (In the forum post the developers discussed posibility of obsidian "native" function call for metadata [2])

[1] https://trello.com/b/Psqfqp7I/obsidian-roadmap [2] https://forum.obsidian.md/t/super-fr-enhance-obsidian-with-a-type-system-for-notes-and-database-like-views-metadata/46444

[promethean]

+1 for this. as an example use case, I use inline img:: property extensively as a quick visual snapshot of a file's contents. Database folder provides good support for this, so I can quickly scan the screenshot associated with each note. Am keen for Projects to replace DB Folder - so please do add this in !

One thing though - when parsing images from inline properties, they'll be formatted as ![[img.png]] - so in gallery or db folder view please do ensure they render !

[ertugruluyar-github]

If these feature happen, then ı can add progress bar to my projects!!

[alancunha26]

Any news on that?

[marcusolsson]

I've been going back and forth on this.

Based on the feedback I've gotten so far, the main request seems to be able to edit inline attributes.

Until the :: notation gets adopted either natively by Obsidian, or in the wider Markdown community, I'm considering it to be a syntax for Dataview. The problem however (as you know) is that Dataview projects are readonly, which aligns with how Dataview was designed:

From the Dataview docs:

Dataview is about displaying, not editing

Dataview is meant for displaying and calculating data. It is not meant to edit your notes/metadata and will always leave them untouched (... except if you're checking a Task through Dataview.)

Even in the author's new Datacore project, there's no sign of support for editing metadata.

Moving forward

The way I see it, there are (at least) two approaches here:

1. Make Dataview projects editable: This would be my preferred approach. If you're using :: in your notes, you're most likely using Dataview already. One of the most common questions I get is why you can't edit data in Dataview projects. So I'd love to address it. Unfortunately, this is tricky to implement due to the Dataview API being designed for querying only (as mentioned above).

2. Keep Dataview projects readonly and support the :: format in other data sources (Folder and Tag): In my eyes, this would be a workaround to address the limitation of not being able to edit Dataview projects.

Since I'm currently blocked on the first approach, that leaves the second approach as the pragmatic way forward.

Implementation

Introducing another format means that Projects need to decide which format to use when editing a given field:

For example, imagine that you want to edit the values V1, V2, and V3, in the table below:

name	published	due	priority	status
First note	frontmatter	inline	inline	inline
Second note	V1	V2	inline	frontmatter
Third note	frontmatter	frontmatter	V3	frontmatter

• V1: The user seems to prefer using front matter in the other notes, so we could guess that it should be frontmatter as well.
• V2: In some notes, due is an inline attribute, and in some a front matter. Here, I'm not sure we can guess accurately, and we'd need a Preferred field format under settings, as an arbiter.
• V3: This seems tricky to me. The user seems to prefer front matter in this note, but uses inline attributes for this field in general.

We could have a global setting for the preferred format, and allow the user to override the preferred format per field. That way, you could say, "in general I favor front matter, but for the author field, I want to use inline attributes.

To simplify the problem, we could restrict the format per field, i.e. you can't mix formats for a given field across notes. We'd still need to support reading multiple formats for a field, but once you edit them, the configured format for the field takes precedence.

That begs the question of what happens when you edit a note where the field is an inline attribute, but the preferred format is set to front matter. Should you keep the current format, or convert the field to the preferred format. I'm leaning towards the latter.

There are probably other edge cases I'm missing here, but I've listed a few to get the conversation going.

[ccll]

That begs the question of what happens when you edit a note where the field is an inline attribute, but the preferred format is set to front matter. Should you keep the current format, or convert the field to the preferred format. I'm leaning towards the latter.

How about treat the in-file format as default where the field is declared, then if the field is not declared anywhere we go with the global prefered setting.

In-file declaration is "more specific" than global settings, this is similar to CSS overriding rules or some Linux software config file overriding rules, it's "expected behavior" for people I think.

[axelson]

The heuristic that makes sense from my (limited) point of view is:

• If the field already exists on the note then edit the field where it is
• If the field does not exist on the note then add it to the frontmatter

I think this will be very understandable from the user's perspective and reasonable to write and maintain from an implementation perspective. Although it won't please everyone.

I think one of the difficulties with the ability to add an inline field is that there's many options for where to place the new inline field since it could be at the beginning of the document, somewhere in the middle (even in the middle of a sentence) or at the end of the file. So some user's would want the ability to customize the setting of where to add the field for each field.

Perhaps one way to provide additional flexibility is to provide a bulk editing option to move a given field to be only in the frontmatter or only an inline field.

[ccll]

If these feature happen, then ı can add progress bar to my projects!!

Further experiment turns out it's actually can render a progress bar in the Project Table View now with dataviewjs-in-frontmatter, even in a 'Folder based project'.

As long as the 'rich text formatting' is enabled for this field.

With this frontmatter:

---
parent: "[[InfraOps 基本操作]]"
status: Backlog
created: 2023-01-20
due: 2023-03-15
due_in: |
  ```dataviewjs
  if (dv.current().created && dv.current().due) {
    const start = moment(dv.current().created.toString());
    const end = moment(dv.current().due.toString());
    const now = moment();
    const totalDays = end.diff(start, 'days');
    const passedDays = now.diff(start, 'days');
    const dueDays = end.diff(now, 'days');
    dv.el('div', 'in ' + dueDays + ' days');
    dv.el('progress', '', {attr: {value: passedDays, max: totalDays}});
  }

progress: 80% bar: "$= dv.el('progress', '', {attr: {value: parseFloat(dv.current().progress), max: 100}})" type: "FEATURE" priority: 2

Unfortunately it looks like the dataviewjs does not run in Board View:
![image](https://user-images.githubusercontent.com/5366582/215242117-1e7f2489-a89c-4d80-a229-0811ddf39a8f.png)

Despite we can run dataviewjs-in-frontmatter from Table View now, there is still great value for supporting "::" inline properties.

For me the greatest value is that "::" properties can be "inherited" from a Template and override it in a generate note with a little help of embedded dataviewjs code in the Template itself, this allows one to modify the template and add properties after notes are created, the notes will automatically pickup the new properties. And you can't do this with Frontmatter properties, once you created hundreds of notes from a template, and you find out you need to add some Frontmatter properties to the template later, you are screwed!

[daamiian]

Is there an update on this?

[robz0]

This would be great in Projects. Inline fields are recognised in db folder somehow. As long as they have already been defined in a note somewhere in it database source.

The feature should not need to full funcationality of editable dataview, just recognition of the inline fields and whatever the protocol/restriction or whatever it is that tells when the field value entry has ended. I think this may have to be anything up to a return/new line? not sure.

[melMass]

This would be very useful, just realised it wasn't working while trying to migrate from kanban.

As mentioned this is supported in DB Folders and also dataview query based tables are not in "read only" mode there. If the later wasn't true (not sure why this is the case I could not find much info regarding this) we could rely on dataview which can perfectly read inlined fields

My hope was to replace both db folders and kaban by projects but these issue are blockers to my workflow I believe

[marcusolsson]

@melMass You can find more information on this in the FAQ.

Until Obsidian supports inline attributes natively or they become wider accepted in the Markdown community, my stance is that they're a Dataview-specific format.

The real issue here is that Dataview projects can't be edited. The solution is make Dataview editable, not to add inline attributes to the other data sources.

Unfortunately, the main challenge is that Dataview is designed for reading data, not modifying it. Since the Dataview API doesn't support writing data back, this plugin would have to reimplement parts of Dataview to support it (which I assume the other mentioned plugins have done).

Parsing inline attributes in Projects introduces significant complexity and performance implications. The best solution here would be to have the Dataview project support write operations to their API. However, I suspect they'll give you a similar answer.

Right now, I have no plans to implement this.

[melMass]

Thanks for the detailed answer I'll check the FAQ! Yes you are right that the writing back part must be a custom implementation, I discovered that after my comment! DB folders seems to do it well!

In case someone was ready to give it a go would you review a PR?

[marcusolsson]

Before working on a PR, I'd like to see a design proposal that addresses the concerns I've listed.

[nununo]

As much as I'd love to see this implemented, I fully agree with @marcusolsson. It's prudent to first see what Obsidian comes up with for metadata so that we keep things as standard as possible. Let's make sure everyone is rowing in the same direction.

[melMass]

Before working on a PR, I'd like to see a design proposal that addresses the concerns I've listed.

I was referring to implementing a write api layer for Dataview in projects (I'm on my phone so not 100% sure if it's DBF, but I think it is, they have a quite elegant solution IMO (I looked deeply yesterday)) edit: I think this part -> https://github.com/RafaelGB/obsidian-db-folder/blob/master/src/services/EditEngineService.ts

but I fully understand opinions expressed here. I will actually start from scratch on a new add-on and see how it goes!

[MaxwellWibert]

@marcusolsson I'd like to draw your attention to the Metadata Menu plugin. I think it's just what we need to overcome the challenges in making dataview projects editable. Like MetaEdit, it can create/initialize and update metadata attributes on documents. However, unlike MetaEdit, it seems to have a robust way of dealing with both inline and frontmatter attributes. Take a look at this section of their API docs. The API's postValues method seems to have a very reasonable set of behaviors that should satisfy the obsidan-projects' use cases.

• If an attribute exists, postValues will update the value in place, regardless of whether the attribute is inline or in the frontmatter.
• If an attribute doesn't exist, the function will add it to the note. By default, the new attribute will be inserted into the frontmatter, but you can also specify an optional line number to say where the attribute should be added.

I personally think this seems like a great behavior to expect from editing metadata in projects. If someone has gone out of their way to format a note's metadata inline, an edit from projects won't mess that formatting up. If no formatting is present, we simply default to the Obsidian native formatting. Perhaps if some users are very gung-ho about putting all their metadata inline, we could add a few of radio buttons in the dataview project's settings page that let you choose where your new attributes go, something like:

• [ ] frontmatter
• [ ] inline start of note
• [ ] inline end of note

To be honest, even this choice seems like above and beyond what is required for a fairly intuitive and functional interface.

postValue also has options for formatting an attribute as a list. We could, for example pull an attribute's value into projects normally, and if it exists we check if its value is a list. Then users edit said list in project's internal state and when they save, the attribute's value (in the note) is updated to the new list (from project's state).

[MaxwellWibert]

@Acylation I would also love your input on this proposal given your participation in issue #672 . @marcusolsson Would it make more sense for me to post this as an issue?

[MaxwellWibert]

Hey, just wanted to see if anyone else had thoughts about this? Are there any major obvious obstacles, other than time?

[Acylation]

@MaxwellWibert Sorry for the delayed reply and thanks for the following-up. Yes the time is the critical point. I'll be busy till December for my grad school admissions, and will have lab works at the mean time. The feature of editing dataview projects requires substantial changes in both the UI and data backbone, needing a sustained period of work. Another problem is my novice coding skills. I’m learning as I go along, which sometimes results in me getting stuck on basic issues.

Technically, a passable and compatible UX can be achieved according to your suggestion and your survey. As marcus pointed out, we can start with a simple implementation and then gradually refine the feature until it’s stable. While the main concern always lies in the detailed design. Along with inline fields, we may be expected to handle more in-text info, such as headings (mentioned in #697), tasks (requested in #149, #164, #442), inline tags. These items are supported by different level, like the inline metadata is a dataview specified format, and the tags is officially supported and accessable via Obsidian api. Choosing an api to satisfy these needs at the same time would be an ideal solution.

I've also checked the in-progress datacore plugin. In place editing would be supported according to its roadmap. I'm looking forward to its implementation, but won't wait for this to move on this issue.

TL, DR; I'd like to work on this but my time is limited, and there are some design work in prior to actually coding on this.

[LynetteCullens]

Work Around: Use MetaBind Plugin's inline Input Fields as Default Value Now, how do I make a dummy table where my frontmatter doesn't automatically add extra fields that I created in order to edit in the table?