ID DownloadScreen: User feedback: something (`fee_waiver_request_download`)

[MPLP-Docassemble]

Question ID	DownloadScreen
Details	The first line of each address (plaintiff, defendant, both lawyers) is indented a bit from the rest so it looks like this:

Kim Cramer 15 S. Washington Suite 102 Ypsi, etc. Variable being sought | fee_waiver_request_download Package version | 0.3 Filename | docassemble.FeeWaiverRequest:data/questions/fee_waiver_request.yml

[normon66]

I've noticed this oddity before and it goes down to base docassemble functionality.

@ekressmiller - do you happen to have any insight on why it was done that way?

[ekressmiller]

Hmmm, I hadn't noticed this before, but now I see. So if we have multiple inputs being added in a single PDF field, the first one gets indented. In this example it happens with the phone number. Are we talking about the same phenomenon?

- plaintiffs_address_block: |
    % if user_ask_role == "plaintiff":
    ${ users[0].address_block() } 
    ${ users[0].phone_number }
    % elif user_ask_role == "defendant":
    ${ other_parties[0].address_block() } 
    ${ other_parties[0].phone_number }
    % endif

I can think of some workarounds (like separating the PDF fields and/or using address_block(), but that does seem kind of buggy. Can you confirm if I'm correctly understanding the issue and then I can ask on Slack?

[normon66]

How I interpreted Kim's finding, as with what I've seen in the past, is how address.block() puts a space at the beginning of the city/state/zip line. This appears to come directly from the block() function in al_general.py:

If the standard two-space indents are used when populating the field in an attachment block, the first line actually appears indented since it takes the spaces literally:

If the indents are removed from the attachment block, we see how the CSZ line is indented [from the block() function]:

It seems like the workaround for this scenario is to use a single-space indent. This way, the street line and phone number pick up the single space from the attachment block and the CSZ line picks up a single space from the block() function.

Does this help / make sense? @ekressmiller

[ekressmiller]

Yes, thanks, that's interesting. Do you think it makes sense to flag to the AL folks? I guess if that space weren't there in al_general.py you'd still have to be conscious of your spacing in the attachment block since it's changing things based on the amount of indent.

But a 1-space indent is an unusual thing to have to do.

[normon66]

Per today's call: @ekressmiller - yes, please see if the AL folks or Monday crew have any insight or feedback on this. Thanks!

[ekressmiller]

@normon66 this is still on my list to raise with the Suffolk folks, a couple other things just took priority. Will circle back once I do so we can implement the fix you identified (single space indent) if needed. It does look a little funky on the output.

[ekressmiller]

@normon66, it sounds like this is something that might get fixed in AssemblyLine, but no particular timeline.

In the meantime, the single space indent solution or using line_one() and line_two() instead probably make sense. The latter probably preferred since if they do fix it, the single indents will probably screw things up again. (For Mako programming in Docassemble, the default is no indent at all.)