Our app has dozens (possibly over a hundred) parameters that need to be configured by users (things like cutoff dates, defaults for various lookups, and all kinds of things like that). In our old environment there was a concept of a single record file that was always active and we used that.
What is the best way to handle this type of thing in the CUBA world? It needs to be available anywhere, from any screen, and needs to be editable from a normal edit screen (which will be locked down to certain users of course; I know how the security works).
I’m getting to the point where I’ve got to start working on a solution for this, and I’m not finding anything helpful in searches, etc - does anyone have advice? This has got to be a very common need I’d think.
The only standard solution that came to my mind is to use Config Interfaces.
Create a ConfigInterface ( SourceType.DATABASE) with the parameters you need
Use these parameters where needed: Inject config beans and use its data to initialize bean values, etc.
Users (application administrators) will be able to update config values using Application Properties editor ( Administration > Application Properties).
You may need to create a custom application properties editor screen if the standard one doesn’t meet your requirements.
Yeah, I saw that. I’d need a much more user-friendly screen for editing them. Also the documentation isn’t super clear. It says “Config interfaces must be defined inside of the root package of the application (or in inner packages of the root package).” - where, exactly, does that mean I need to put the class? It’s not clear to me from that. Outside of any module, or…?
can you elaborate a little bit on what are the target users of that screen? Is it an tech-savy administrator or really a business person?
Generally speaking I would say that you either really just leverage config interface mechanisms and optionally put another abstraction layer of UI on top, or you create a dedicated entity for a particular configuration type and make the UI therefore a little bit more domain specific.
Note that config interfaces also incorporate caching, which is most likely what you want to have, right? When doing custom config entities you have to keep that in mind and implement it on your own (which is not super trivial in particular when working with a clustered environment).
If you give a little bit more details on the different types of the configuration perhaps we can speak more concretely about it
These are things like start and end hours of the day for the appointment scheduler, days of the week that they want to have available for scheduling, start and end dates for cut off dates for entries into the general ledger, start and end dates for cut off date range for invoice dates, defaults for things like visit type, service sites, numerous (dozens of) other lookup tables, just things like that.
Yes, it’s admin-level stuff but the built in UI is not exactly that friendly.
But I totally agree, the built-in nature of the config system is very attractive.
so if you want to make it end-user friendly configuration UI I think you “simply” have to develop it. Perhaps this is why you don’t find so much in the forum about it because the people probably just model it as part of their app development.
One good example of this is the Odoo ERP system that has such a UI:
As you see there it is correctly modeled on the UI side and probably also on the entity layer side.
In case the configurations that you want to do are in particular tables, then I think you will hit the limit of the configuration interfaces really quickly. Also, the different datatypes are making it hard to treat it as a generic thing.
Probably the most pragmatic approach is to define one global entity / one entity per subcategory (in the example about it might be something like GeneralSetting, CrmSetting, ShippingMethods) and only have one instance in the database. For the 1:N relationships, you can then connect it to ShippingMethods e.g. which contains multiple instances.
