Does the root note in every workspace have to be called

root

?

as of today, yes. you can change the title but the file name will be

root

In a multi-vault workspace, can I make it so that a given vault has a hierarchy prefix?

I want to ctrl L and type

devex.

to refer to stuff in the devex vault, and

personal.

to refer to the personal vault

I guess in my workspace I have to alter my yaml with a name for each?

no, that still doesn't work the way I expect it to

it wouldn't show up in the tree view today. the closest you can get today is by changing the vault name to the given prefix and then use the prefix as a hierarchy inside that vault. open to suggestions and feature requests in this area 🙂

yeah, okay. I guess my expectation is that every vault has a name and that name is its root in the hierarchy

the cost of which is that you cannot have name collisions, vault must be unique inside a hierarchy

so if I have two vaults mounted side by side, they must not have the same name

If the future (as I understand it) is that vaults are fungible and can mount one another, then this approach also means that if I have vaults A, B1 and B2, then I cannot mount B(1) and B(2) at the same point in the hierarchy

and if you wanted to go one level more complex, vault aliases would allow users on-disk flexibility and mounting alongside one another

so I could put B1 and B2 next to each other if I said "alias B2 to Foo"

and then, no conflict because B1 and Foo do not conflict. Even though behind the scenes,anything in Foo is actually in a vault whose native name is B

I am doing a poor job of explaining this but I could write something up

I also am shooting from the hip here, need to read the RFC about the future of workspaceless vaults more carefully to understand how and where this is headed

One last question: right now all the notes are stored in the root of the vault as

path.to.notes.md

. Trying to look up if it's possible to store notes in actual subdirectories like

path/to/notes.md

inside each vault

> so I could put B1 and B2 next to each other if I said "alias B2 to Foo" so we actually talked about this and working around this using [import maps](https://github.com/dendronhq/dendron/discussions/2349#discussioncomment-2171472) (though out of scope for the initial release) definitely give the rfc a look and would welcome your opinion > One last question: right now all the notes are stored in the root of the vault as path.to.notes.md. Trying to look up if it's possible to store notes in actual subdirectories like path/to/notes.md inside each vault not today. but in the future of self contained vaults, this will be a thing

- vault
    - README
    - assets/
    - notes/
        - root.md
        - ...

Love the direction that all of this is going. Will read the rfc. Thank you!

And excited to get my team using this

I have a schema

plan.schema.yml

that I use for the

journal

entry in

dendron.yml

. When I use the

Lookup Bar

(i.e., or the corresponding shortcut) it creates a journal note and the

title

in the

yml

front-matter has, as expected, the full date, i.e.:

yml
id: 0bohCP3PzaKTnRGIDMVeL
title: '2022-02-18'
desc: ''
updated: 1645176234689
created: 1645176234689

However, when I create a note manually via the

Lookup Bar

(e.g., typing

plan.2022.02.19

), only the day is used for the title in the front matter (i.e.,

title: '19'

. Is there a way I can manually create such a note with the full date? I hope this is clear. This is how my schema looks like (i.e., based on the guide in the wiki).

yml
# The `dendron.yml` file.
# ...
workspace:
# ...
    journal:
        dailyDomain: daily
        name: plan
        dateFormat: y.MM.dd
        addBehavior: asOwnDomain
# ...

yml
# The `plan.schema.yml` file.
version: 1
imports: []
schemas:
  - id: plan
    title: Planner
    desc: Planner implementing the capture-configure-control system.
    parent: root
    children: [year]
  - id: year
    title: Year
    pattern: "[0-2][0-9][0-9][0-9]"
    template: temp.plan.year
    children: [month]
  - id: month
    title: Month
    pattern: "[0-9][0-9]"
    template: temp.plan.month
    children: [day, days]
  - id: day
    title: Day
    pattern: "[0-3][0-9]"
    template: temp.plan.day
  - id: days
    title: Days
    pattern: "[0-3][0-9]-[0-3][0-9]"
    template: temp.plan.day

Hi team, is it possible for dendron to prohibit the creation of a note if the name does not match the schema?

OK, interesting. The workspace is in Dropbox, so I opened Dendron on the laptop and the images showed up (including the image with the leading '/' removed as kevins8 suggested). Went back to the imac where the notes were created, still no images. Quit out of VSCode, restarted, displayed that note and the images are there.

Hey, @User , No, not to my knowledge. Schemas suggest note names, but they won't prevent you from creating notes that don't fit the pattern. I do dimly recall someone asking about this previously though. Let me check.

Aha, found it 😁 [Support strict hierarchies through schema](https://github.com/dendronhq/dendron/issues/588). Please, upvote it or leave a comment to show your support for this issue. I also think it's a good candidate for

crop

(https://wiki.dendron.so/notes/tayowNP4tMvcqH7AraoQ4/).

https://github.com/dendronhq/dendron/issues/2451 opened

This is a known problem atm. I recently opened a bug for this

This is a known limitation at the moment. We are planning to solve this with the note traits system: https://wiki.dendron.so/notes/bdZhT3nF8Yz3WDzKp7hqh/

Concerning the bug we talked about yesterday (

Cannot read property 'title' of undefined

) @User: I managed to reproduce it by copying and pasting a note in the file explorer side panel, and then deleting it again (not through lookup and "delete node") at first I thought it was because of using the file explorer panel, but that wasn't the case. The note I was copying and deleting had the same ID as another note, which seemed to mess up something, my guess is the cache now the question is, is that something that needs to be fixed, if yes how? my suggestion would be to make it more obvious if a note has the same ID, for example with an inline error message at the id line, as well with an easy fix (with the light bulb symbol in vscode) do you know what I mean?

Ah that would definitely do it I think! Because Dendron will think the note is already deleted (since the deleted note had the same ID). This should be something Dendron handles gracefully though. I think the easiest way to handle this would be to show a warning when the note is added that the ID is a duplicate. I'm not sure that this is the same issue as the one Soto Ducani filed, although it may be related. Would you mind sending a bug report as well, or at least commenting on that issue to add this?