App
App copied to clipboard
[$250] Task - No error of exceeding limit when changing title of existing task & system message posted
If you havenβt already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Version Number: 1.4.53-2 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: N/A Issue reported by: Applause - Internal Team
Action Performed:
- Go to https://staging.new.expensify.com/
- Navigate to any report
- Click on "+" > Assign task
- Enter title and finish creating a task
- Open the created task
- Click on Title and change to anything > 100 characters
- Click on "Save"
Expected Result:
The error is displayed in the title editor that the field is exceeding limit of 100 characters, and user can not save the long title
Actual Result:
The error is not displayed in in the title editor, the title gets updated briefly, user is returned to the task report, and the system message of updated title is posted. There is only one error message in the task report that the title is too long
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
- [x] Android: Native
- [ ] Android: mWeb Chrome
- [ ] iOS: Native
- [ ] iOS: mWeb Safari
- [x] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/78819774/7009c399-32b6-4595-8b56-701c751f082f
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~0141fff112dde5aafe
- Upwork Job ID: 1770200502191382528
- Last Price Increase: 2024-03-25
- Automatic offers:
- Krishna2323 | Contributor | 0
We think that this bug might be related to #vip-vsp
Proposal
Please re-state the problem that we are trying to solve in this issue.
Task - No error of exceeding limit when changing title of existing task & system message posted
What is the root cause of that problem?
We don't have logic in validate function to check task title length and show error on task edit page. https://github.com/Expensify/App/blob/c915e7f026eddc710dd01a38abc3afc9334002ae/src/pages/tasks/TaskTitlePage.tsx#L31-L39
What changes do you think we should make in order to solve the problem?
Update the validate function to also check for length just like we do in NewTaskTitlePage.
https://github.com/Expensify/App/blob/c915e7f026eddc710dd01a38abc3afc9334002ae/src/pages/tasks/NewTaskTitlePage.tsx#L38-L49
Pseudo-code:
const validate = useCallback(({title}: FormOnyxValues<typeof ONYXKEYS.FORMS.EDIT_TASK_FORM>): FormInputErrors<typeof ONYXKEYS.FORMS.EDIT_TASK_FORM> => {
const errors: FormInputErrors<typeof ONYXKEYS.FORMS.EDIT_TASK_FORM> = {};
if (!title) {
ErrorUtils.addErrorMessage(errors, INPUT_IDS.TITLE, 'newTaskPage.pleaseEnterTaskName');
} else if (title.length > CONST.TITLE_CHARACTER_LIMIT) {
ErrorUtils.addErrorMessage(errors, INPUT_IDS.TITLE, ['common.error.characterLimitExceedCounter', {length: title.length, limit: CONST.TITLE_CHARACTER_LIMIT}]);
}
return errors;
}, []);
Result
Proposal
Please re-state the problem that we are trying to solve in this issue.
No error of exceeding limit when changing title of existing task & system message posted
What is the root cause of that problem?
We have a check in the edit title page only when the title is empty but not when the character length is more than 100 characters: https://github.com/Expensify/App/blob/c915e7f026eddc710dd01a38abc3afc9334002ae/src/pages/tasks/TaskTitlePage.tsx#L31-L39
What changes do you think we should make in order to solve the problem?
Update the Validate function to check for character length as follows:
[!NOTE] We don't need to use
ErrorUtilsover here, this is a unnecessary function call and redundant, using local valuetitlewill be more efficient and fast. Also we have already defined the type of the errorsFormInputErrors<typeof ONYXKEYS.FORMS.EDIT_TASK_FORM>, so no need to useErrorUtils
const validate = useCallback(({ title }: FormOnyxValues<typeof ONYXKEYS.FORMS.EDIT_TASK_FORM>): FormInputErrors<typeof ONYXKEYS.FORMS.EDIT_TASK_FORM> => {
const errors: FormInputErrors<typeof ONYXKEYS.FORMS.EDIT_TASK_FORM> = {};
if (!title) {
errors.title = 'newTaskPage.pleaseEnterTaskName';
} else if (title?.length > CONST.TITLE_CHARACTER_LIMIT) {
errors.title = ['common.error.characterLimitExceedCounter', { length: title.length, limit: CONST.TITLE_CHARACTER_LIMIT }];
}
return errors;
}, []);
Result
https://github.com/Expensify/App/assets/110545952/faf1785c-05ca-4e84-be38-ba4ae3dc8b2e
@lanitochka17 No one was assigned to this task, can you reapply the labels please :) thanks
Triggered auto assignment to @kevinksullivan (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
@kevinksullivan FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors
I would put this in VIP-VSB, since it's tied to task management. I would put this as a LOW issue in terms of priority though, because this is only an issue AFTER the task is created, and the error works well when creating the task with > 100 characters
Job added to Upwork: https://www.upwork.com/jobs/~0141fff112dde5aafe
Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)
Proposal
Please re-state the problem that we are trying to solve in this issue.
- Task - No error of exceeding limit when changing title of existing task & system message posted
What is the root cause of that problem?
- We do not validate the task title length if its length is greater than 100.
What changes do you think we should make in order to solve the problem?
- The exceeding limit character is a common error, and is used in whole the app, but currently, we handle it manually. For example, with the task description, we need to handle it in the validate function as below: https://github.com/Expensify/App/blob/ddf9e7ae25fcc9b0a2516ed341947ad38130b36f/src/pages/tasks/TaskDescriptionPage.tsx#L38-L46
- And we need to do a similar thing with other forms we need to limit the character, leading to duplicate logic.
- So my solution is, we will let the FormProvider component handle it automatically. Below is the details:
- First, we need to create a new variable, named
limit, to differentiate itself from themaxLength - Then, add the below logic to this one:
Object.entries(trimmedStringValues).forEach(([inputID, inputValue]) => {
if (inputValue && inputPropsRef.current[inputID].limit && inputValue.length > inputPropsRef.current[inputID].limit ) {
ErrorUtils.addErrorMessage(validateErrors, inputID, ['common.error.characterLimitExceedCounter', {length: inputValue.length, limit: inputPropsRef.current[inputID].limit}]);
}
})
- In the above,
inputPropsRefstores all the input props. - Then, if we need to limit the character, for example, in this case is task title, just need to use:
<InputWrapper
limit={100}
What alternative solutions did you explore? (Optional)
- Also, we can just need to add
maxLength={100}to this one to prevent user from typing more than 100 characters
~@GandalfGwaihir's proposal looks good to me!~
@Krishna2323's proposal looks good to me!
π π π C+ reviewed
Triggered auto assignment to @blimpich, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@thesahindia Do you have any feedback about my proposal (which will reduce redundant code in future)? cc @blimpich
@thesahindia, I think the selected proposal is a dupe of mine, can you pls check again.
cc: @blimpich
@blimpich @thesahindia, @GandalfGwaihir added the note below which I don't think makes sense and I think they are just confusing in the name of unnecessary function call and redundant. ErrorUtils. addErrorMessage is being used in multiple places. Pls let me know your views. The NewTaskTitlePage also uses ErrorUtils.addErrorMessage. They totally copied my proposal then tried to add a redundant.
We don't need to use ErrorUtils over here, this is a unnecessary function call and redundant, using local value title will be more efficient and fast.
@GandalfGwaihir, please refrain from using the π emoji as it is very annoying and would not help justify your duplicate proposal. If you have any valid reasons, please do reply to my comments. Otherwise, please refrain from using the emoji as it is not going to help anyone in any way.
Hello @Krishna2323 , sorry if you felt that annoying (I really am :) ), i was just trying to avoid unnecessary arguments and fights because the C+ has already selected the proposal, but if you want some context on why they (C+) did select my proposal, please refer to the form guidelines below, thanks and hope you understand :) let's collaborate together and be a part of this awesome community :smile:
https://github.com/Expensify/App/blob/3d780639eb260c1165e884032f4a92aa7dbbb4ca/contributingGuides/FORMS.md?plain=1#L127-L152
@GandalfGwaihir, I think you need to look at the form guidelines. Thats the reason why we use ErrorUtils.addErrorMessage in NewTaskTitlePage.tsx.
https://github.com/Expensify/App/blob/3d780639eb260c1165e884032f4a92aa7dbbb4ca/contributingGuides/FORMS.md?plain=1#L154-L174
We are validating title twice. There is a reason why we use ErrorUtils.addErrorMessage in NewTaskTitlePage.tsx.
https://github.com/Expensify/App/blob/c915e7f026eddc710dd01a38abc3afc9334002ae/src/pages/tasks/NewTaskTitlePage.tsx#L38-L49
Let me know if you want more examples, we even use ErrorUtils.addErrorMessage where we don't even validate twice.
sorry but i won't be able to explain further after this, in NewTaskTitlePage, we have not defined the type for errors:
https://github.com/Expensify/App/blob/c915e7f026eddc710dd01a38abc3afc9334002ae/src/pages/tasks/NewTaskTitlePage.tsx#L39
But in TaskTitlePage we have defined the type:
https://github.com/Expensify/App/blob/c915e7f026eddc710dd01a38abc3afc9334002ae/src/pages/tasks/TaskTitlePage.tsx#L32
So no need to use the ErrorUtils here :)
Also you need to know the speed of validation too, in my proposal, the time complexity here is O(1) with space complexity also O(1)
sorry but i won't be able to explain further after this
Because you don't have a valid point. We are using ErrorUtils in NewTaskTitlePage and there is no such value addition in your proposal, you just added a false claim and copied RCA and solution from my proposal.
Using ErrorUtils won't break anything, and now you are talking about speed of validation.
In both TaskDescriptionPage & NewTaskDescriptionPage, we don't even validate description twice but still we use ErrorUtils.addErrorMessage. All I wan't to say is that using ErrorUtils.addErrorMessage doesn't have a downside and it must be used when we validate twice.
https://github.com/Expensify/App/blob/3d780639eb260c1165e884032f4a92aa7dbbb4ca/src/pages/tasks/NewTaskDescriptionPage.tsx#L48-L54 https://github.com/Expensify/App/blob/3d780639eb260c1165e884032f4a92aa7dbbb4ca/src/pages/tasks/TaskDescriptionPage.tsx#L38-L46
@thesahindia can you elaborate on why the selected proposal was chosen? I'm not particularly knowledgeable on our standards for forms and would be curious to hear if there was anything specifically that made you choose one proposal over the other?
@Krishna2323 please refrain from using accusatory language. This is a community and everyone deserves to be given the benefit of the doubt so we can make the best software possible.
@blimpich, sorry for that but I was literally annoyed by π reactions of the contributor when I was only asking C+ for a second look.
Upwork job price has been updated to $250
Reducing the price of this since it is a low priority bug and is a fairly simple.
Yeah makes sense ;)
@blimpich Currently, the logic to validate the max length limit is handled separately. Or to put it another way, we need to call it for each input field we need to limit length. That leads to the duplicate logic. So we also should consider handling it generally, as I mentioned here
Yes I think we should consider handling it generally, though I'm not sure how big of a lift that would be. If we went with that we would ideally also change all existing instances of where we create limits for text inputs to use the new format you propose right? I'm not sure how big of a change that would be or if it would be high risk for regressions. Again, I'd like @thesahindia's thoughts on this.
If we do like that, IMO, I suggest 2 options:
- Option 1: There are ~15 existing instances and we can update them to use the new format.
- Option 2: Only apply the new format to fix the current issue, and will use that format in future components