Forum Discussion

rchrenewables's avatar
rchrenewables
Contributor 2
22 days ago

Job Form Additional Characters

Hello,

Does anybody utilize the job forms for providing findings for clients? I have been using the job forms and just recently noticed that the "long answer" option isn't quite long enough for some of the job findings that I write up for certain jobs. Does anybody have an efficient work around for this? 

Cheers, 

6 Replies

  • Just thinking here, but what about a second question below the long answer that says "Continued if Required"?

    • tbarth's avatar
      tbarth
      Contributor 3

      Clever! 

      I tested the long answer box, and it does seem to be limited to 4096 characters.

      • rchrenewables's avatar
        rchrenewables
        Contributor 2

        That’s not a bad idea! Thanks for the responses. It may not be a character limit rather than a formatting issue. The report attached below recently had this issue. Page 3 just goes straight into photos. 

         

  • krista's avatar
    krista
    Jobber Support Team

    Hi everyone,

    This is a really good callout, especially if you are using job forms for detailed findings or formal reporting.

    I would be happy to pass this along to our Development team, particularly around the character limitation and the formatting issue you mentioned. That context is helpful.

    In the meantime, have you considered using internal notes for longer findings? Notes do not have the same structured character limitations as form fields and can sometimes provide more flexibility for detailed write-ups. Some teams use job forms for structured checklists and then use notes for extended summaries or conclusions.

    • tbarth's avatar
      tbarth
      Contributor 3

      It looks like long multiline forms in the mobile app are clipped in the form field, in this case with lots of short lines. If desktop shows the full content, the backend data is still there. I'm assuming the behavior happens on iOS and Android since they both use React Native, which you guys switched to a few years ago.

      The current TextInput implementation probably uses a fixed height or limited auto-grow without enabling scrolling past the maximum height. Any parent container constraints or missing scrollEnabled could cause it as well. Android has a vertical alignment thing that may also cause it if not accounted for.

      Should be an easy fix.  Looking at the React Native reference:

      • TextInput with multiline={true}
      • Dynamically grow height using onContentSizeChange up to a defined maxHeight
      • Enable scrolling past maxHeight (scrollEnabled={true})
      • Set textAlignVertical="top" for Android alignment
      • Wrap in KeyboardAvoidingView and ScrollView if the form spans multiple fields or page height

       

      Example:

      <TextInput
        multiline
        value={value}
        onChangeText={setValue}
        onContentSizeChange={e =>
          setHeight(Math.min(e.nativeEvent.contentSize.height, 400)) // auto-grow until max
        }
        scrollEnabled={height >= 400}    // allow scrolling past max
        textAlignVertical="top"          // fix Android vertical alignment
        style={{ height, minHeight: 100, maxHeight: 400, borderWidth: 1, borderColor: '#ccc', padding: 10 }}
      />

      That would prevent clipping, works on iOS and Android, maintain the layout, and handle keyboard interactions and flex layouts correctly.

      Or I could be completely wrong about the exact cause, but it should still be an easy fix since it's certainly a css issue.

      As for QA, this is the kind of issue that can slip past all of the non-manual / device testing test methods, including E2E because simulated keyboard and layout stuff can behave differently from real devices.  Even then, it's an edge case for manual testing.