What's the best way to create custom fields for each user / client?
I have an application that is being marketed as SAAS to multiple clients. As expected, sometimes customers want to customize some areas of the application by adding their own fields, in particular the area related to tracking activities / projects. We are currently allowing a small amount of this. It is handled by storing additional field names for each client in a db with an ID for each field. Any values are then stored in a second table, which has a column for each potential data type (String, date, etc.). This table lists the ID of the custom field and the key of the object to which it is attached. This way we store all the custom field data in one table. I wouldn't worry too much about it if it was limited to a small number of fields for a strange customer, but now it is seen as an opportunity for sales and customer service to quickly customize the app for individual customers.and in some cases, getting more custom fields than were originally in the subject in question.
I have convinced people that for now we have to stick with these large-scale settings, and I tend to be of the opinion that if you want this behavior, you have to build it correctly, that is, create the appropriate database tables, etc. ... There was another question that mentions two ways to implement this in the database here . One of the solutions is similar to the one described above. Another is to have a bunch of redundant fields in tables that need to be customized called Text1, Text2, Date1, Date2, etc., which can then be used as per users' request, renaming them in the gui accordingly.
I was wondering How did someone else solve this problem? what were the limitations for solving them? and any further reading suggestions I might make.
amuses,
source to share
We are also developing SaaS and we also have clients looking for all sorts of customizations.
Where it can be more or less useful to all clients, it has a fixed implementation. Value, tables and fields. The feature is enabled or disabled by some access right that belongs to the user's package.
We also have another situation where users are allowed to dynamically define fields and their associated subfields to create their own forms. It is as difficult as anything. Here we are using a kind of Entity attribute value model to meet these needs.
This is the case with an "enterprise" application, perhaps with their unique feature - the client wants something exotic and we can't say no.