[New plugin] Modal form - integrate forms into QuickAdd, templater, etc

Happy to see that you are enjoying the plugin!
Currently the select notes doesn’t have any strategy to “exclude” files or folders.
However, as a workaround, you can use a dataview query which could have the same effect (and opens even more posibilities)

So, instead of source note you select dataview, then use the following query:

dv.pages('"Data" AND -"Data/Nested"').file.name

Where Data is the root folder and ‘Data/Nested’ the subfoder you want to exclude. I suggest you copy paste this, because dataview is very sensitive to spaces and quotes, For example, adding a space between - and "Data/Nested" will fail. Or forgetting to add the extra quotes " will also fail.

I’m thinking about creating a new thread for people showcasing and asking for workflows around the plugin, and leave this thread only for new releases.


For future reference, I added this to the advanced examples section of the docs:

@danielo515 Hi and thanks! These Templater‑related shortcut actions seems really powerful but complex. I suggests two things: dynamic inline code that creates buttons to execute forms and URI scheme that could be used to execute forms from clickable links. Modal form could itself offer built‑in feature to add dynamic buttons into notes which could utilize URI scheme.

Note that there’s also Advanced URI and Shell commands plugins which implement some properties‑related actions — although it remains unclear how they can enhance repeated properties actions. As I wrote to you earlier it could be nice to hear some of your thoughts about workflows involving repeated properties interactions with the same note. Most of the time properties interactions are important at the note creation which means actions triggered by templates in note creation. One of these actions could be customizable input forms which is the idea of Modal form. However consecutive properties actions that happen after note creation are different and to my knowledge only two community plugins try to implement some kind of user‑friendly interface to these customizable actions that could be triggered at any time: captures or macros in QuickAdd and defining commands using Shell commands plugin. If just properties are involved in these consecutive actions — simply Properties view could offer very powerful solution.

1 Like

What an exciting plugin! I’m still finding my way around the features and have already found great use cases. Just wondering about the “Templates” tab in the Edit form section - can you point me to some documentation explaining how to use this feature alongside Quickadd?

I’m guessing it gets called up in the “return result.asDataviewProperties();” line of the Capture format section in Quickadd settings?

Hello @blue_emperor , I’ll try to answer your questions the best I can.
The first thing I want to emphasize is that I only want to add features that can be used as building blocks, so users can build the workflow they may desire without me having to implement every permutation of one specific task. This is important because keeps the plugin focused, easier to maintain, and the most important, easy to use. Too many features is as bad as too few.
With that out of the way, I will try to answer your questions. First, I’m not sure I understand what do you mean with “dynamic buttons”, but if you mean that you want a button that could open a form, that is already possible combining moda-form with other plugins, specifically Templater+buttons. You can create a template that opens a form, then tell templater to create a hotkey for that template, which in turn creates a command that you can execute with a button. You can then embed this button in any note you want. This may look complex, and it is, but with rare exceptions you need a template anyway to process the form results.

The problem with ‘repeated interactions’ is that they can only be achieved in a limited way. Rendering a template into a note is a destructive operation: once you have created the note, it is impossible to deduce from it the original template that originated it, not to mention that people can add, modify or delete text from the note. However, you can use a form to edit the note frontmatter/properties, because they are in a well known format that is easily machine readable, this is the only reliable repeated interaction you can do. I already posted an example to do this, let me know if you need me to link to it or if it is not what you mean.

As you mention, QuickAdd offers some kind of repetitive interaction with existing notes, and that is good. And, you can also use modal-form in combination with QuickAdd, so when you trigger a capture it opens a form, then the result of that form will be inserted as the capture. I also have an example of how to do this in the plugin docs, let me know if you need a link to it or if it is not doing exactly what you expect.

Templates is a feature that, can be considered “beta” for now. The idea is that, for many forms, you don’t need the full power of templater, and all you need is a smple template to format/put the values in the right places.
Right now, the template can only be used when you execute the command “create note from a form”, which will ask you the destination folder, the note title, open a form and create a new note using the form results and the template.
I try that every feature is self-documented, how can the text in the templates tab be improved to make it more clear.

I think it will also be nice to be able to use the template directly from the note results, like results.renderTemplate() or something like that, so you can insert the template in any place, not only newly created notes.

Nothing big, just wanted to announce that I have published a dedicated docs site:


Thanks for the great plugin!
I was looking for a convenient way to edit properties (especially a quick way to edit tags property) and the method shown in the link(Advanced - Obsidian Modal Form docs)
seems to work well.

I have a few questions and requests regarding the input of this form.

  • I place tas property fields at the top of the modal, but when the tags type field is at the top, it is in focus from the beginning and the suggestions choices are shown, so the existing tags are hidden as shown in the screenshot. Is it possible to either not show the suggestion choices when no character is entered, or to display the existing tags above the input field?
  • If I am not mistaken, Ctrl+Enter is assigned for Submit when the focus is on the input field of Tags type or Text type, but it does not seem to work when the focus is off. If possible, I would like it to work even if the focus is off.
  • I would like to define a Select type field in Modal Form for a text type property (file_type in the screenshot), and select a value from a list of static choices. However, even if I try to edit a note that already has a property value, the top choice in the list is selected on the form, and if I click Submit as is, the property is overwritten with that choice. Is there any way (or alternative) to make the choice selected from the beginning if a property has a value that matches the choice of the select type field?

Importing Forms

Since release 1.40.0 it is possible to import forms from JSON.
You can open the import modal from the command palette or from the forms list.
The command is called Import Form for the surprise of no one.
That will present a simple modal with a text area where you can paste the JSON.
Any errors will appear next to the text area if any.
Once you fix the errors you can click the Import button which will open the form editor with the imported form.
From there you can do any changes you want and save it.


This is using the default obsidian input suggester. I don’t know how much control I can have over it, but I’ll have a look. The answer for the current state is no, it’s not possible right now.

This looks like a bug. Do you mind opening an issue in github so I can track it down?

Hi @danielo515
Firstly, I want to thank you for a great app. I’m using it mostly for frontmatter modification and works well. It will come in handy for my mobile app too, when I get a chance to set it up.

My question is along the same lines as the question that @larryeitel asked in Oct 2023. Will you be adding dataview functionality to allow us to pull text from a file to use as values in a “select” or “Multi-select” list?

For example, I have a note called “Account Types” and that note has the following text separated by newlines. No frontmatter, no lists, just text to be used as a lookup.

Master Reseller

I would like to be able to use the following Dataview query to return a list of strings for use as a selection.

dv.array(await dv.io.load(“Classes & Lookups/Lookups/Account Types.md”))

But if I use the await command, I get the error “Error evaluating the dataview query”. If i wrap the above in a dv.paragraph() or dv.list() function in a normal note, it will display the list as shown above.

Would including this in the code be possible?

Hello @Cyberpunk , before I offer any guidance, I need to understand what do you want to do with that. A form, is usually a collection of field + value pairs name: John, age: 36, what I see there is just a list of values.
Or are you suggesting that you want to convert that to a form with those as input fields? If that is the case, I can provide a little bit of code that you can use in any templater template (that you can invoke however you want). If we came to a solution that can be documented in the modal forms docs.

Hello @danielo515 . 1st: thank you very much for this plugin. its quickly become one of my favorite & most used obsidian plugins since I have discovered it. I’ve run into this exact issue noted by @Cyberpunk and was looking for a potential solution when I found this forum post so I have decided to contribute to the conversation. Hopefully this can provide you with some additional insight.

I am trying to create a select field in a form with select options from a matching field I have defined via the metadata menu plugin, which I am also using. In this case, the async is specifically required in order to wait for the metadata menu api to return the correct field options. Here is a screenshot from my vault that should demonstrate what I am trying to achieve. You can see the dataview query with its outputted result in the file on the right. I am also open to other ways this could be achieved. Feel free to tag me if w additional questions. thx again for the awesome plugin!

1 Like

An update: I spent a couple days poking around the code and was able to get a working fix on a feature branch of a forked repo. I’ve never written in Svelte before (more exp w React) though thankfully I hardly had to touch any of the UI and gpt4 was able to help with what little I did. This was also my first experience with fp.ts and I had too much trouble messing around with TaskEither. As a result my code changes likely are not consistent with the rest of the functional codebase though there are only a handful of files with changes. I also attempted to limit the code I added to only run on async dataview queries. I am open to making a pr to the main repository if this is something that other people would like to use. I would also like to be able to merge it so I can continue to receive new updates, though honestly I am fine just having this part working locally bc now I can create select fields with values queried from any other obsidian plugin I have installed

Maybe you could submit a draft PR?

1 Like

An excellent idea, thank you. I always forget about draft PRs. I put one up just now

Mmm, I thought that all my function evaluations were made async for this exact reason. But the evaluation of DV queries was one of the first, so maybe that is not the case, I have to check it out.
It may also happen that what is really missing is the app in the context. For security reasons, all functions that are executed as part of a form are heavily sandboxed, and only have access to a restricted set of values.
Have to check it out

Now that I re-read this I notice this is just another victim of the lac of async support for dataview queries.
To be honest, I never thought it was a requirement because all DV queries are just syncrhonous, but seems that people really need this feature.

@zaye I appreciate the effort put into adding support.
However, the expectations that I have for the codebase is to keep following the same functional style, and the correct thing to do in that context is to use TaskEither.
That said, your PR was a great inspiration, and I will be adding this functionality myself very soon. Thank you

1 Like

Just a preview of what this enables. Here is a example snippet fetching from a remote api

      .then(response => response.json())
      .then(json => console.log(json))

And how it looks in the final form:

1 Like