Announcement

Collapse
No announcement yet.

EspoCRM v7.2.0 released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • EspoCRM v7.2.0 released

    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.
    ‚Äč
    Last edited by yuri; Yesterday, 06:38 AM.

  • #2
    Thank you so much, great job!

    Comment


    • yuri
      yuri commented
      Editing a comment
      Thank you for help with finding and fixing bugs.

    • Kharg
      Kharg commented
      Editing a comment
      It's a pleasure helping this project.
      Now please, get some well deserved rest!

  • #3
    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.
    Last edited by yuri; 09-14-2022, 07:42 AM.

    Comment


    • #4
      Great job Yuri!

      Thank you.

      Comment


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

        Comment


        • murugappan
          murugappan commented
          Editing a comment
          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
          yuri commented
          Editing a comment
          5 min is quite more than I expected. It took less than 1 min for instances I upgraded.

        • murugappan
          murugappan commented
          Editing a comment
          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.

      • #6
        https://forum.espocrm.com/forum/bug-...rror#post83592
        Last edited by TripitakaBC; 09-29-2022, 05:07 PM. Reason: Bug report on case-sensitive value name validation error.

        Comment


        • yuri
          yuri commented
          Editing a comment
          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.
          Last edited by yuri; 09-29-2022, 07:47 PM.

        • TripitakaBC
          TripitakaBC commented
          Editing a comment
          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
          murugappan commented
          Editing a comment
          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.
      Working...
      X