Enhanced Dynamic Logic

[telecastg]

Free plugin that enhances Espo's Dynamic Logic capabilities with three improvements:

1) Ability to change a field's css specifications (background color, text color, font weight, etc) based on Dynamic Logic conditions.

2) Ability to view the changed css in detail and in list views.

3) Ability to use the current User attributes (isAdmin, isPortal and Team membership) as conditions to apply Dynamic Logic directives (standard like visibility, readonly, etc. or the new css specifications) to a record.

This plug in can be downloaded here: https://github.com/telecastg/enhance...ic-for-espocrm

See the README page for installation and use instructions.

The enhanced Dynamic Logic capabilities are not accessible form the Administration module, they require modifications to an entity's clientDefs and record views, but hopefully the Espo development team will find these improvements useful and can integrate them into future versions.

[tothewine]

I look forward to an upstream merge!

[item]

Thanks telecastg
i will try.. front-end is not my skill

[esforim]

Hopefully someone will help. Reading the readme at the moment and it still it will require copy/paste or coding at this stage. Looking forward to updates.

[telecastg]

Hello everyone, just released version 1.0.2 which adds the ability to use Roles as a dynamic logic condition.

By the way, I have also been experimenting with the EXCELLENT dynamic handler feature https://github.com/espocrm/documenta...mic-handler.md and in my opinion will help a lot improving form design and user experience. I highly recommend checking on it. I am experimenting using it as a "front end" hook not just to manipulate fields appearance but also to actually modify the model on the fly based on user interactions.

Saludos :-)

[peterberlin]

Hello telecastg,
It would be very good if the user ID was a condition for 3) .
peter

[telecastg]

Hello Peter, do you mean the actual user ID record number ?. It would be possible but you would have to hard code the number in the entity's clientDefs. Can you tell me more about the business case/application that you have in mind ?.

[yuri]

I also recommend using dynamic handler: https://github.com/espocrm/documenta...mic-handler.md

It's not planned to implement an ability to check user fields in dynamic logic. It's built in a way that only fields of the current record can be used.

[tothewine]

Can we have a default dynamic handler that uses ajax to make calls to a controller/service we can then extend with custom class ?

[peterberlin]

Hello telecastg,
my question referred to the ID of the logged in user. Yuri has not confirmed the realization for this.

But it would be very good if you could change the properties of the fields with formula.
peter

[telecastg]

Hello Peter,

As I mentioned, it would be possible to establish the current User Id as a Dynamic Logic condition, but it would require to hard code the target User Id in metadata as an input.

Dynamic Logic (original and enhanced) are front-end (client-side) implementations so they occur immediately, before the data is sent to the server, while Formula (in my opinion) is essentially a user friendly way to write a Hook which is a back-end (server-side) implementation so it happens after the entity has been modified in the front-end but depending on the hook it can happen before or after a record has been updated in the database.

So in that sense Dynamic Logic is client-side and Formula is server-side so they are not compatible.

What would be desirable for Administrators not wanting to deal with coding metadata, is to be able to include the enhanced dynamic options in the field Administration facility as part of the Dynamic Logic section but that requires changes to Espo's application files and would not be "upgrade safe".

[tothewine]

username instead of id probably makes more sense to hardcode a 'fixed' string rather than the id

[telecastg]

I completely agree, just would like to learn more about the end purpose (business case) for making GUI changes based on s single individual identity.

[Oleksii S.]

Hello telecastg,
I need to exclude some options of the Enum field depending on the Current user: If CurrentUser IS NOT CreatedBy one.
Is it a case within the topic?

[telecastg]

Hello Oleksii,

If I understand correctly, you want to change the enum options of a field based on the condition that the current user is or is not the record creator.

You can do this with Dynamic Handler https://docs.espocrm.com/development/dynamic-handler/

Follow the example provided in the documentation and adapt to your own entity.

To test if a user is the same as the one who created the record, use this condition inside the function "controlFields":

    if(this.recordView.getUser().id == this.model.attributes.createdById) {
        // set the options for your enum field when the current user is the person that created the record
    } else {
        // set the options for your enum field when the user is NOT the person that created the record
    }

[Oleksii S.]

Thanks, telecastg !
But what I asked about is your plugin.
I`d like to see a cloud/box instance as flexible, as god`s clay, so a hard coding is a last option.
The dynamic logic, as a tool for data restriction, lacks some power, so I wonder if your plugin could help.
What I can see for now, I`d wish attributes-comparing operators and mentioned Current User properties.
If this is realizable by kind of simple installation of the plugin, I`d try to use it, till Dear Developers will implement some in native.
Or maybe, you could let it as a payable extension, for an option.

[telecastg]

You're welcome Oleksii S.

At present the enhanced dynamic logic plugin does not cover placing restrictions on enum fields.

The plugin only covers the same types of changes as the out-of-the-box dynamic logic:
- Show or hide a field
- Show or hide a Panel
- Make a field read-only
- Make a field required
PLUS: Change a field's css (color, background-color,font,etc) in detail and in list display.

Regarding the type of conditions that can be evaluated with the plug they are the same as the out-of-the-box dynamic logic:
- The attributes of another field and comparisons (greater than, less than, contains, not contains, etc)
PLUS the current user attributes (isAdmin, isPortal, Role membership, etc)

Also at present, the plug-in does not have an Admin interface and requires some coding because it overrides the out-of-the-box dynamic logic. It is more of a tool for developers than an Administrator feature. I can't promise but I will check the possibility to make it more "user friendly" in the future when I have some time.

For your current goal, I think that the new dynamic-handler is more appropriate and although it requires some simple coding it can be a very useful tool to learn.

[Oleksii S.]

At present the enhanced dynamic logic plugin does not cover placing restrictions on enum fields.

Why not? Don't forget "Conditional options".

…out-of-the-box dynamic logic:
- The attributes of another field and comparisons (greater than, less than, contains, not contains, etc)

… and those are restricted with implicit values. I wonder if nobody else ever wanted to compare fields one with another.

For your current goal, I think that the new dynamic-handler is more appropriate and although it requires some simple coding it can be a very useful tool to learn.

Sure it is, but I think of two-stage system deployment - quick start-up, and deep customization. And this tool is rather of the second.

[manny18]

I agree with Oleskii. Lack of current user/role/team base Contitional Options support is a big drawback. For example, if option A B instead of A B C D are supposed to be shown based on a condition, when I create a new one, that condition is going to work as ALL fields are empty at this point. So on UI , we end up seeing A B C D as options. The only work around now is to force the user to save it first by filling out the condition field , then go back to edit it to see option A and B.

[Oleksii S.]

I use another way, more restricting: clear forbidden options by formula, when they've been chosen by user. But this is awkward.

[telecastg]

Espo, out of the box, allows a high degree of customization from the Administration module, but these facilities, just as any first class "code generator" can do, will work hopefully for 90% of the customization needs of hopefully 90% of the users because they are meant for the widest use possible, so by definition they can not accommodate all use cases.

Of course it is always possible to request features from the developers but there is no guarantee that they will find a suggestion compelling enough to justify the effort and investment required for development and maintenance of the additional code.

To achieve a higher degree of GUI customization, beyond what is provided by the Administration module, will require either coding or hiring a developer to create the necessary code.

For those willing to do some basic code, Espo provides dynamic handler https://docs.espocrm.com/development/dynamic-handler/ , a single script where you can write highly complex logic to modify the display and characteristics of fields in any entity and even writing some front-end "hook" like functions without having to mess with writing custom views, controllers, etc.

I have included some enhancements to this class as part of the enhanced-dynamic-logic free plugin latest release. https://github.com/telecastg/enhance...ic-for-espocrm and also posted a step by step tutorial, for those interested, on how to apply custom logic, including manipulating options of enum fields, changing field colors and using User properties to achieve highly customized GUI effects. https://forum.espocrm.com/forum/deve...gic-conditions

Saludos

[esforim]

Just regarding the 2nd paragraph, don't be afraid to try your luck or revive an old thread! Some of my feature request manage to get approve so was quite happy that a feature become reality.

Not all feature request was accept, but the more important one did.

Keep forum alive.

[telecastg]

I totally agree that making feature requests is important to keep the forum alive and to give first hand feedback to the developers, and I would also like to see more developers sharing their implementations or solutions to enrich this fantastic framework and make it even more appealing and increase its adoption.