I would like to create an "App Settings" section that is for my application settings and configuration items. It needs to have both UI builder tree items (such as lookup values from the database) as WELL as content sections (from a /settings root node, for example). This is because I'm storing my settings in different ways depending on what they are. Database lookups, for example, are in UI builder as they are needed for integration at the db level. Email notification templates and lists of users are only needed within umbraco, so they can be content. (I mean I could make them all UI builder tables - but it's much quicker to make them document types and content). I know I can make a UI builder virtual tree appear elsewhere, although it currently wants a foreign key - which I don't have for some of my settings. What about the other way round? Is it possible to have a virtual content tree ? That way I can keep the content section limited to "what the user's consider" to be content, and settings (which are in fact content but they don't consider them content), elsewhere. uSkinned for example has a single root "configuration" content element with a custom list view - which is an approach I might take - although it'd be even nicer to put the settings somewhere else.

Would your editors still be able to see the

/settings

node?

I would prefer not

I'm not sure if it's relevent for sub-trees, but I did something simliar where I "aggregated" data sources using the REpository within UI Builder. https://docs.umbraco.com/umbraco-ui-builder/advanced/repositories

cs
protected override Person GetImpl(int id) {
       // expects Person return
       // does not care where you fetch it from
    }

Maybe it can be achieved similar for tree items (or a table view may be sufficient?)

Interesting. I already have a repository that does some filtering - it provides a single ui builder entity that represents a sub-table, but I didn't consider having a UI builder repository that is a layer over top of a content tree

Yeah, then your "tree nodes" can then be static as it'll be a logical seperation rather than a programattic one. 🙂