Removing a subfolder from the vault changes its nesting level

[uli-on]

Seems like removing a subfolder from the vault always moves it up onto the top level. I've tried with level one (sub) and two (sub-sub).

[uli-on]

I forgot mentioning, this is manual order, not alphabetic, not by date, I didn't try these.

[alialbaali]

What do you think is the right way of handling that?

[uli-on]

What do you think is the right way of handling that?

Well, I'd expect such a folder to *stay where it was.*

[alialbaali]

What I meant is that, if you have a folder, within another folder, and both of them are vaulted; Unvaulting the subfolder shouldn't unvault the parent, and that's why the unvaulted subfolder becomes a top level parent. However, if you unvault the top parent folder, any subfolders should get unvaulted too. Which is how currently it is implemented.

[uli-on]

Let that explanation come up ad give the user some options?

[alialbaali]

The only thing that might need fixing is that, if you have a folder within a subfolder, and the parent isn't vaulted, but the child is, unvaulting the child should move it to be the child again, and not become a parent.

I think that's what you mean by creating this issue, right?

[uli-on]

I'm not really versed with nested vaults, I've tried vaulting for the first time last week.

But since we have the "birds eye view" of the tree of nested folders, it looks as if it's quite easy to operate: you can access any folder from this perspective and give it a property (here: the vault, the quality "vaulted"). As a user with birds eye view, I don't care for what is vaulted on which level and what is not. This POV would immediately change if we could access " inner" folders of the vault (children) only by opening up outer folders (parents), i.e. if nested folders would be displayed among notes.