I'd have to be light on the changes. Given the previous example, I'd override the default list() instead of the core getallsettings.
Re the question u posed. With authord as an example. I'd introduce an authorSite table in the module. That's as far as I got but I'd imagine I just follow suite with what we discussed for settings to modify author service and entity.
Yeah, I am talking about your current method. I no longer use single databases for ORM stuff.
What I found is when I did this approach many times in the past, each site would still require things that other sites wouldn’t need.
And so I can now see the same problem with your approach here.
With ORM it is actually much easier to use multiple databases, as an example I blogged about this not long ago.
Sorry but for ORM and multiple sites this approach is far better, and simpler. With ContentBox the more I think about it, the more it can’t be core for your approach. And your only solution would be to do what you had been going to do, but please be very aware that future updates to ContentBox will mean you are then constantly changing your code to match these changes.
It is also because of the many reasons that I am now thinking about, this will never be a support that will be supported in ContentBox, and the approach that I blogged about listed above would mean no changes to ContentBox would be needed for it to work on multiple sites.
I think now that I have really thought about it, you are going to need to change your views on a single DB for multiple sites. I asked the question how do you handle data in a row or even a table that is not for another site, I asked that question for a very good reason.
When I switched to ORM and the approach above, I did so for very good reason. It allowed for the same features, same sharing of data. But it also meant that some data could be site specific and not be included in sites that do not need it.
After working on a very larger Application where one database controlled around 76 sites, the amount of data that was redundant on other sites bloated the database beyond belief. Now this might not be the case for you, but I am going to say it is also not flexible if that case ever is actually needed if you continue with the one database scenario.
Data can be migrated, very easily. Problem is ContentBox and other applications to integrate into your single DB application, means that you may as well just write those modules to begin with. Because that is basically what you are in need of doing.
Sorry for changing my mind here, but I see more problems than it is worth to even contemplate what your asking.