Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inline edit fixes and improvements #10537

Open
wants to merge 2 commits into
base: hotfix
Choose a base branch
from

Conversation

pgorod
Copy link
Contributor

@pgorod pgorod commented Oct 4, 2024

Description

This PR...

  • makes inline edit use only one back-end request instead of two, sometimes three. This improved speed is quite welcome, not just to allow users to move faster, but also to prevent UX errors such as when people redo or undo an action accidentally because of a delay. If you've used inline edit with a not-so-fast server, you know what I mean...
  • moves a couple of auxiliary functions from Home controller to inlineEditing.php
  • adds the standard validations, as defined in vardefs, to inline editing: callback, range, isbefore, less, more, binarydep, comparison, in_array, verified. Adds a new one, isafter.
  • makes inlineEditing.php customizable
  • fixes a few minor bugs

Closes #8886
Closes #9818
Closes #10237
Supersedes #8858
Supersedes #10240

Thanks to @gunnicom and @SinergiaCRM for their code or comments in those previous PR's, they were very useful to me in this work.

How To Test This

I suggest starting by adding this callback example that @gunnicom provided to the Opportunities vardefs, name field:

modules/Opportunities/vardefs.php

    'validation' => 
    array (
      'type' => 'callback',
      'callback' => 'function(formname,nameIndex){
                           var fieldvalue=$("#" + formname + " input[name=" + nameIndex + "]").val();
                           var returncode=true;
                           if(fieldvalue.trim()!=fieldvalue){
                               add_error_style(formname,nameIndex,"Space at the start or end of value not allowed " + nameIndex); 
                               returncode= false;
                           }
                           return returncode;
			}',
    ),

... then QR&R.

Now test with:

  • random places throughout the app, doing inline edits
  • number validation: test with Opportunities Probability (between 0 and 100)
  • callback validation: test with Opportunities name adding spaces in the beginning or end
  • int validation: test with Calls duration hours

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Final checklist

  • My code follows the code style of this project found here.
  • My change requires a change to the documentation.
  • I have read the How to Contribute guidelines.

@pgorod
Copy link
Contributor Author

pgorod commented Oct 4, 2024

Known Issue: there's an edge case that doesn't work so well: in 'isbefore' validations, typically used when there are date ranges involved (start + end dates), the validation is only in effect in one of the two fields. In normal Edit views, both fields will be validated, so it's enough for one of them to throw the error.

But in inline edit, if you inline-edit the other one, no validation will take place, even if two relative dates are out of order. To fix this we would need also a isafter filter, and set validations on both fields. I added the code for that new validation type, but I didn't go and check all the vardefs where isbefore is used. I don't think this is worth much trouble, if somebody really cares about this, they can update their vardefs.

Note that my PR doesn't introduce the problem, it was there before... I fix a lot of other things, though not this one. I provide means to facilitate fixing it, that's good enough for the time available to work on this... 👼

@serhiisamko091184 serhiisamko091184 added Status:Assessed PRs that have been tested and confirmed to resolve an issue by a core team member PR 9-14 Score given to PRs once assessed Status: Needs Feature Review Status: Requires Code Review Needs the core team to code review labels Oct 15, 2024
@serhiisamko091184
Copy link
Contributor

Hi @pgorod,

Thanks for your contribution!

Regards,
Serhii

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR 9-14 Score given to PRs once assessed Status:Assessed PRs that have been tested and confirmed to resolve an issue by a core team member Status: Needs Feature Review Status: Requires Code Review Needs the core team to code review
Projects
None yet
2 participants