-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide IConfiguration extensions to configure certain modules #6036
Comments
And perhaps setup in such a way that the settings would first come from IConfiguration, but optionally overridden by Site Settings? This way, e.g. SMTP settings can still be configured from the dashboard, while taking advantage of defaults being configured using app settings.json, ENV etc. |
Original issue discussing this one, with a focus on the email settings #4611 It was tried, and reverted, because there was no reflection in the ui to indicate that the settings had been overridden. No trouble with someone trying todo it properly, but the key part for me, is that it must be made clear in the ui where the settings have come from, or if there are defaults provided by Also super easy to do currently (yourself) by registering your own |
Exactly. One idea that crossed my mind was perhaps a user should explicitly tick some checkbox that lights up the settings in the UI, switching readonly fields to writeable. But it doesn’t completely solve the issue of making clear what settings are in effect if you then uncheck again if you don’t want to lose the overriding values. Some applications that support layers of settings solve this using a tabbed UI, where you have one tab showing the settings coming from some source (IConfiguration for instance), another tab where you can override some values, and a tab showing the effective settings. But that’s a lot of UI, and I wonder if that’s worth it. At the same time, being able to setup build pipelines with configuration values provided by environment variables from e.g. containers is a must IMHO. Arguably more important than having the ability to change settings from the admin screen. I say arguably, because it depends on the user using the system. So probably it’s worth the effort. Let’s think some more about a smart way to do the UI that (ideally I think) doesn’t involve 3 tabs 🤔 |
That is a lot of ui, indeed.
Arguable, and the argument is totally dependant on the user of the system. But I agree, the build pipelines argument here is strong.
Maybe one idea could be to make it an either/or feature. I.e. it by default comes from the UI, but as a feature, only comes from The feature could include a And you could require the feature on during host Not as flexible, but maybe covers both requirements? |
I think the good thing with having just extension methods that you could use in your web app's Startup.cs, is that then it's up to you to communicate it appropriately if necessary and you can decide which configuration wins if there are overlapping ones. Imagine a public SaaS scenario: You don't want people to need to configure SMTP for their sites, because you'll have an SMTP server for the whole platform and want to use it on every tenant automatically. Possibly you want people to allow using their own SMPT, possibly you want to prohibit this. You configure this in appsettings, or Azure App Service configuration. OK, but then what should the SMTP Settings page say? A warning? Should it be inaccessible? I don't think there is a one-size-fits-all solution (especially that you can override those settings just partially too) so I'd go the easy way (at least for now, possibly revisit based on feedback) and say it's up to you: Orchard provides the optional capability to override settings, you decide what happens after that. E.g.: For your own apps you'd use this in a way that appsettings always wins and you don't care about the UI. For customers' individual sites that you host maybe appsettings would be a default, and your admin customers could override it from the admin; you communicate this in a wiki or something. For your public SaaS appsettings always wins and you make the SMTP settings page inaccessible. And yeah, of course, you can do all this without having extensions but it would make things easier. Imagine just a five-ten minute googling and whatnot for everyone doing this the first time, a lot of effort saved if there are thousands. I wouldn't consider this a super high priority though, of course, there are more important things. |
There is also an other issue with this when it comes to support also an appsettings.development.json file for example. Tenants are currently not taking this into consideration when I tested 2 weeks ago. There are a lot of implications in using this. Some modules depends on their configuration, now if you enable the module it can show a UI to edit the settings afterward. But if you are using an appsettings.json file and that your module is enabled, if your settings are not properly set you need to make the proper validations on your module to not fail loading. Example of that is with the OrchardCore.Shells.Azure module. |
@Skrypt as i remember we checked together that it takes into account the app level appsettings.development.json ;) also the one directly under app_data, but higher level config sources may override some values. Maybe we would have to consider settings as another level of config sources and following the same conventions of the configuration stack, maybe as we implement e.g the tenant specific appsettings. Most of the time config sources are immutable, this is when there are mutable that it becomes more complex. But would need more time, so here just a first thinking. E.g we have a higher level tenant sepecific appsettings.json in the tenant folder (can be from blob) that we can edit and save, but we only save a config that doesn't already exist with the same value in the lower level config sources, but when we edit it we saw the result of all the config stack, not only the ones that are persisted in this specific config source. |
True it takes it into consideration but we can't use it with empty values or null values if we'd want to override values set in the global one. It doesn't allow transformation like with web.release.config XML transform. |
To use with empty or null values, to disable an option, is an interesting thing to do with It's not really how it is designed (from an ASP.NET Core pov). It would be possible to add a So currently there is no way to read the configuration, and noop, before replacing the services. |
Let's see how they handle this case with common services in .net core. I'm pretty sure you are right about this. |
Okay, i don't remember the details but yes you're right we talked about it. So i re-did a little test with this in
And an
And this in the code
Where i got respectively
|
Yes, was just referring to the Re: settings in development, perhaps better to carry that discussion out over on #5808 rather than hijack @Piedone related / but different issue? |
Ah okay, indeed here we can't use a tenant level
Oups yes you're right ;) |
One thing to keep in mind also is that we should obfuscase all values in the admin ui as mentioned here #6294 |
Closed by #12033 |
Reacting to your remarks @sebastienros under https://www.youtube.com/watch?v=vLQqQYGl_Xo&t=1010s. You're right that this issue wasn't selected for 1.x. However, this is rather that the issue was forgotten than an intentional no-go, and apart from that, I don't really see how this was "force pushed" as you mentioned:
|
Is there's an issue for the extension that we added? I might need to watch the recording first |
No technical issues. |
I just watched the Seb's comment, as @Piedone mentioned earlier all the things made in PR, but is this mean for all the Lombiq related PR that we need to mark them as So, please let us decide how everything should go to avoid any conflict Thanks |
If the problem is that this issue apparently never was officially triaged, then I'm sorry about that and will make sure next time that it'll be. Then again, this is an ancient issue, and nothing was rushed or forced. |
Several modules expose their configuration via
IOptions<T>
but only include a site settingsIConfigureOptions<T>
for it: Email, Facebook, GitHub, Google, Reverse Proxy Configuration. These could also provide extension methods like OrchardCore.Shells.Azure does withAddAzureShellsConfiguration()
so the configuration can be easily provided by e.g. the appsettings.json file.The text was updated successfully, but these errors were encountered: