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

unclear behavior of increment function in the Number field #3384

Closed
GeethaParthasarathy opened this issue Jan 6, 2023 · 4 comments · Fixed by #3422
Closed

unclear behavior of increment function in the Number field #3384

GeethaParthasarathy opened this issue Jan 6, 2023 · 4 comments · Fixed by #3422
Assignees
Labels
bug Something isn't working Forms
Milestone

Comments

@GeethaParthasarathy
Copy link

Describe the bug

When we have a number field and a form input number provided to it say "5" when we try to apply the increment to it by entering a increment value to it say 10, the increment does not apply to the input value provided rather starts from 0 and increments by the number provided for increments. It is not clear how the increment should be applied to the input value,

Steps to reproduce

  1. Create a new form
  2. Add a number form element
  3. To the number field add a form input value as "5"
  4. In the properties panel enter the increment value as "10"
  5. Click on the up arrow in the preview of the number field we could see that the increment is not applied to the number inputted but starts from 0
dd3a1cd5dd4885632899e2fce9b15222.mp4

Expected behavior

Unclear behavior of increment function in the Number field

Environment

  • OS: [ Windows 10]
  • Camunda Modeler Version: [5.7.0 rc-1]
  • Execution Platform: [ Camunda Cloud]

Additional context

No response

@GeethaParthasarathy GeethaParthasarathy added the bug Something isn't working label Jan 6, 2023
@nikku nikku added the Forms label Jan 6, 2023
@Skaiir
Copy link
Contributor

Skaiir commented Jan 9, 2023

This is expected behavior, the increment doesn't dictate the amount that the arrow increments by, but rather the increments which are valid for the field.

It seems here that the confusion is more one of language than anything else.

@Skaiir Skaiir self-assigned this Jan 9, 2023
@Skaiir
Copy link
Contributor

Skaiir commented Jan 10, 2023

Ah, actually there's a bigger bug at play here, the validation for the increment doesn't work anymore. If the validation was there the behavior would be crystal clear. Will provide a fix shortly.

Skaiir added a commit to bpmn-io/form-js that referenced this issue Jan 10, 2023
@Skaiir Skaiir added this to the HTO iteration 13 milestone Jan 10, 2023
@nikku nikku added the backlog Queued in backlog label Jan 10, 2023 — with bpmn-io-tasks
Skaiir added a commit to bpmn-io/form-js that referenced this issue Jan 12, 2023
Skaiir added a commit to bpmn-io/form-js that referenced this issue Jan 12, 2023
@Skaiir
Copy link
Contributor

Skaiir commented Jan 12, 2023

Fixed upstream via bpmn-io/form-js@9b339dc

@Skaiir Skaiir added fixed upstream Requires integration of upstream change and removed backlog Queued in backlog labels Jan 12, 2023
@bpmn-io-tasks bpmn-io-tasks bot added the needs review Review pending label Feb 2, 2023
@bpmn-io-tasks bpmn-io-tasks bot removed the fixed upstream Requires integration of upstream change label Feb 2, 2023
@nikku
Copy link
Member

nikku commented Feb 2, 2023

#3422 restores the validation to provide additional guidance to the user:

capture LGVWaI_optimized

@bpmn-io-tasks bpmn-io-tasks bot removed the needs review Review pending label Feb 7, 2023
@nikku nikku modified the milestones: HTO iteration 13, M61 Feb 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Forms
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants