Multi Enum user defined values

[shalmaxb]

Hi,
ist there any way to make user defined values in a multi-enum field storeable?

I have users with different sets of values and as it is now, they have to input again and again the same values, if they are not in the pre-defined list of values. If they used it for one record, it will not be in the list for another.

I have already tried a lot of things with formula or another entity, where values could be stored and made available by relationship, but nothing worked so far.

[rabii]

Seems that you need another entity which will store default value in a multi-enum and then keep it sync whenever new value is added. if i understand your question correct.

have a look at this : https://github.com/espocrm/espocrm/b...nity.json#L199

[shalmaxb]

I thought of such solution, but so far did not get it to work. I will try again.

[rabii]

if you share how you wanted it to work i will be happy to help. i think you could use the hooks to keep things synced.

[shalmaxb]

Ok, thank you for your help.

In one entity I have a multi-enum, where I store some values by default, which I put in as administrator, where other users do not have access to append or delete values of this list.
I configured it in that way, that the user is allowed to put in own values on the frontend (user defined values allowed). These values do not get stored to the list and are used only for the one record, where the user put it in. That value then is not available for another record, but would have to be inserted again.

When working as an user, you might use the pre-defined values, but would like to extend the list, something that is only possible as administrator.
I could adapt the list for every single user to his preferences, but besides that is a tedious work it would not be update safe. As soon as I update the custom entity, all values would be changed as they are put in in the deployed entity. So, this approach is not viable.

I already tried with another entity, that has its sole purpose to store desired values for this multi-enum field in an own multi-enum field and synchronizes it with this field. I created that entity, built a relationship but did not get it to hand over the values to the enum in the main entity.

One other approach I did was to create an entity, where I had only the name field. I connected the two entities by n:n relationship and every record got listed in the relationship link format (not as an multi-enum). This would work, but I did not get the link values to be concatenated into another text field, which in fact I need. In that text field I put together the different multi-enum values in one field to display that information and also to be able to print it to PDF.

I hope, I could explain understandable.

[telecastg]

Hello shalmaxb

So essentially you would like to have a multienum field that can be appended by a user, but only available to that user ?

[yuri]

This can be solved with little coding.

1. Define a new app param 'userOptions' that returns a list of values for a specific user. Pass `Espo\Entities\User $user` as a dependency.
2. Define a custom field view for your multi-enum field.

...
setupOptions: function () {
    this.params.options = this.getHelper().getAppParam('userOptions');
},
...

[shalmaxb]

Thanks yuri, I will have a look into that, although my coding skills are limited.

[espcrm]

Hey shalmaxb, you should give this ChatAI a try. Since you have some level of programming you might go very far with it. I'm not going to try, I have tried easier "AI" like those art AI (text to art) and failed so I doubt I can do much with ChatAI

[shalmaxb]

Hello shalmaxb

So essentially you would like to have a multienum field that can be appended by a user, but only available to that user ?

Hi, yes, that is right. And the user defined values should be kept even when the entity will be updated.

[telecastg]

yuri solution is a great tip solve the issue of having a User exclusive multiEnum definition.

For the second part of the issue, which is having the ability to add values to the multiEnum dynamically, and that these values be persisted, I believe that it will require to implement a new field type.

I greatly respect the time and effort that you always invest in helping others in the forum, so I will check on a possible solution and will report back. I can't promise that I will do it right away because of time constrains, but it does look like an interesting new type of field worth developing

Best Regards

[shalmaxb]

Thank you, I feel honoured.

[shalmaxb]

Thinking further about this, I came across one additional problem:

In my case, a following calculation depends on what value is put in into the value list. That means, there are values, which have one type of calculation, and other values, that would trigger another calculation.
That means, if a user puts in an own value, the value will not be assigned to one of the triggers, because the app does not "know" which trigger would be required. And I cannot forsee, which possible values would be used in the future.

I think the only viable solution in that case would be to have two (or more) enum-fields with the desired chracteristics (a user would be able to insert persistent values) and assign each to a different trigger as needed. One field to serve trigger one, the other to serve trigger two and so on.

May get complicated with more than one or two different triggers.

Any other idea about a solution for this

[telecastg]

If a User can only have one type of trigger for the multienum options, then you could define the trigger for a given User in the "userOptions: custom parameter.

If a User can have more than one trigger then you would need to have a different multienum field for each type of trigger.

Do you have an actual example that you can describe to better understand the requirements ?

[shalmaxb]

Hi, yes I have an example. Perhaps you know, that my app is a catalogue raisonnée for artists to administrate and document their complete work. The core is a database for artwork of any kind.
Included in this database is a part, where the price for an artwork can be calculated as well as different field constellations regarding the types of artwork, which can be very different. E.g. you may calculate a painting by using its dimensions, so that in the end there will be a consistency in your prices, regarding size, considering works on paper different as on canvas and alike.
But you cannot use this proceeding for digital art like video for instance. You will have in fact many other fields, that would differ between these two types.

To handle that I have a multi-enum, where you at first will choose the type of artwork and depending on that your input mask with all the fields will be different. I realised the switching between different views by field and layout conditions. This basically works as it should.
So far the types of artwork are determined by me as the administrator. I provide a list of types, which I consider reasonable. But that does not mean, that it contains any possible type, which one artist would like to have, as well as there maybe types another artist wouldn`t need. Thus, the possibility to let the user (artist) choose, which type he wants and needs, is reasonable as well.
In this scenario, I would never know, which type one artist might insert. The app itself cannot decide, which would be the parameters to decide, in which scenario a certain type would fit.

That is the point where the problem, that I would like to solve, becomes obvious and it seems quite complicated this way. If a solution would be over complicated, my users would have to accept, that every desired type perhaps will not be possible and those, that are reasonable will have to be put in by me into the provided list, then for everybody.

I hope that is understandable and thank you for your thoughts.

[telecastg]

Hi, would this statement regarding your desired workflow be correct then ?

1) A User chooses from a multi-enum field (the "Controlling" field) the type or types of artwork that need to be priced, for example "Painting"

2) Depending on the user choices, at the "Controlling" field, a second set of fields "Dependent" fields of various types (varchar, multi-enum, enum, etc) will be displayed so the User can enter the appropriate information to provide the input for a formula/computation to be executed. (for example: canvas size, type of paint, etc).

3) For artforms not already pre-defined, the User will add a new entry in the "Controlling" multi-enum. In this case the system displays a message to the User advising that the Administrator intervention is required before proceeding.

4) In the case above, the system alerts the Administrator to define the inputs necessary for the pricing algorithm.

5) Once the new inputs are defined, the Administrator creates the "Dependent" fields and layout and the System sends a message to the User so she or he can enter the information and the system will execute the pricing algorithm for that type of artwork too.

6) When a new type of artwork is appended to the existing definitions, it will be available to other users.

7) The types of artwork available at the "Controlling" multi-enum can be defined for any User.

[shalmaxb]

This could be one possible solution, although the client of mine needing this, would like to have it without involving the admin ( and I would also prefer).

There are two possibilities, that I am trying to achieve for now:

1. create a custom entity only for the enum values. This would make this part completely independent from administrator. The values would be created by the user and could be used by a relationship (link multiple). The only problem with this solution is so far, that I cannot copy the choosen values into another concatenated field. I need this concatenated field to display all the choosen values together for a type of caption (printed in lists etc.).
So the problem here is, how to copy the names of the multiple links into a text field.

2. Another possibility would be to being able to create a user with partial admin rights. I saw that Eymen Elkum has an extension for that and I asked him about it. No answer so far, but I will see.
The problem wth this solution would be, that the user defined values maybe will not be update safe.

Perhaps you have an idea to solve the named problems or any other idea?

[telecastg]

In the scenario that I describe, the only reason why you need to get the Administrator involved is that someone needs to determine which secondary fields to display after a User has created a new "Controlling" option value.

This is required to solve the issue of having different fields displayed based on the value of one multi-enum field.

If all you need, is to persist the User defined options, that can be done with a custom multi-enum field that accepts User created options and those options can be stored as Yuri proposed so they are exclusive to the User that created them.

[shalmaxb]

yes, I understand. The problem in fact is, that depending of the value a user puts in, there the consequences have to be respected, which the user cannot determine. I think, if I cannot achieve a user role with limited admin rights, my idea is not possible to reach without admin.
I will for now wait, what the extension of Eymen Elkum could help and if not, I will stick to the regular way, that the admin has to put in the values and determine the depending consequences.

[telecastg]

OK, let me know if you need anything