EspoCRM v7.2.0 released

[yuri]

Release notes on Github: https://github.com/espocrm/espocrm/releases/tag/7.2.0

Enhancements:

• Detail view tabs #2379
• Bottom panel tabs #2384
• Mass Update: Ability to add/remove items #2310
• Import: Errors panel #2372
• Email: Custom fields support #2366
• Separate view for stream note records #2398
• Varchar/Multi-enum/Array fields: Pattern parameter to check a value against #2360
• Command renaming custom entity type #2318

Improvements:

• Shortcut keys #2393
• Theme improvements #2386
• New Glass theme #2392
• Activities panel: Create icon buttons #2399
• Ability to select multiple records on the list view by holding the shift key #2410
• Ability to reset custom sorting #2376
• Layout manager: Ability to hide a label in the list column header #2359
• Layout manager: Ability to specify list column width in pixels #2358
• Stream: Ability to customize Attachments and Post fields #2357
• Server-side validation for uploaded file extensions #2356
• No need for webserver access to node_modules in developer mode #2352
• Uploading files in chunks #2329

Changes:

• Import: Field validation #2373
• Field parameter readOnly to be taken into account server-side #2375

Security:

• Security headers for client page #2402
• More strict server-side field validation #2374

Front-end:

• Ability to define custom dropdown actions for quick view modal in metadata #2353

All issues: https://github.com/espocrm/espocrm/m...e/136?closed=1


Possible compatibility issues

Rest API

Fields that are set as read-only (field parameter, not dynamic logic) will be ignored in POST and PUT requests. Example: When sending a PUT request to update a read-only field, it won't update anymore.

If you are sending an enum value that is not one of the available options, it will cause a validation error.

Example 1: Sending a status 'Success' when available values are 'Planned', 'Held', 'Not Held'.
Example 2: Sending a value null when the empty value is not in the list of available options.
Example 3: Sending a value 'closed won' when the available value is 'Closed Won'.

Omitting an enum field value in a POST request when the field does not have a default value will cause a validation error.

[Kharg]

Thank you so much, great job!

[yuri]

Thank you for help with finding and fixing bugs.

[Kharg]

It's a pleasure helping this project.
Now please, get some well deserved rest!

[yuri]

If anyone has problems with upgrading, please create a separate topic in the corresponding forum category.

Bug reports posted here are moved to the Bug Reports section.

[Jakub Grufik]

Great job Yuri!

Thank you.

[murugappan]

@ Yuri, I just parse through the changes. Fantastic job! Only one question: Does this upgrade have any Database restructuring?

[murugappan]

yuri thank you for the update. We do not have any large import_entity table. We do not execute much imports as we have integrated Espocrm to our transaction processing systems. I have tested on the dev server and it took less than 5 minutes.

[yuri]

5 min is quite more than I expected. It took less than 1 min for instances I upgraded.

[murugappan]

yuri , i understand. The reason for the length of time is that i am upgrading from version 7.1.4. That means it needs upgrade until 7.1.11 before 7.2.4. Thank you so much.

[TripitakaBC]

https://forum.espocrm.com/forum/bug-reports/83592-error-400-field-validation-error#post83592

[yuri]

It was always case-sensitive, nothing changed. In your case you had not proper values storing in database (what breaks many things, dynamic logic, workflow, reports, etc.). Thanks to the new validation it exposed the problem. I'd recommend running an UPDATE query to fix existing values.

> Sending a value of 'Male' when the option of 'male' is available should be accepted, but is not.

This is wrong. Think of enums with options (AM, am), (MM, mm). Please, no need to argue on this point. I know something how Espo should work.

[TripitakaBC]

Yes, a poor choice of words from me. By 'should be' what I intended was 'used to be prior to upgrade'.

I am sure I will not be the only user in this situation and my intention in posting is to help others diagnose the inevitable errors. It helps me to understand that the error existed previously but the new validation in 7.2.x exposes it rather than creates it. That is a good thing, but we still need to understand how to fix it on our installations. Hopefully, this helps.

[murugappan]

TripitakaBC , very interesting problem. I believe that using the system "as is" and "as intended" without my guys meddling with the core/vanilla code and also maintaining usage consistency would be the way to go. We faced similar problems before but we have now corrected the situation by setting up compliance standards so that it will make life easier for our integration teams as well.

[esforim]

How to enable Bottom Panel tabs? I thought it be the same way as you do with Entity Panel but it not. Is it the "Sticky" option?

[murugappan]

esforim

Its been a long time. May be I can help here.

(1) Select an entity->layout->Bottom Panels and you should see something like in first screencap below.
(2) Under this layout, in the middle box, you can drag and drop a tab-break which will give the second screencap
(3) Enter the tab name that you would like. Remember to drop the tab-break above the enabled item
(4) Define as many as you need and then save and you should get all the tabs defined a in the third screencap
(5) Go to entity record detail view and you should be able to see like fourth screencap (sorry removed) at the bottom of the details

I hope that helps.

[esforim]

Thank you! With your 4th screenshot, not sure if those are private information, you may want to delete if it is.

[murugappan]

esforim, Its ok. the names are fictitious. Anyway, i have removed the screencap. Does my post help?

[esforim]

Sure did, manage to create a few menu... but then I ran out idea after making 2. I'm just not creative enough. But it much more cleaner now, does take a while to get use to. I'm still scrolling down or "hey where my Panel"