When reviewing lists, shouldn't say "you've told us about" said thing

[BryceStevenWilley]

Happens currently if you are editing jobs, see below image:

Happens because it's a check for len(x.complete_elements()) > 0 on the list. Not sure if it'll work but my best attempt at fixing now would be

% if len(x.complete_elements()) > 0`
You've already told about ${ comma_and([item for idx, item in enumerate(x.complete_elements()) if idx != i ]) } 
% endif

Needs to go in several places though, in this repo and maybe in docassemble-AssemblyLine as well.

[nonprofittechy]

I think a better fix is redefining the complete attribute for this list, no?

[BryceStevenWilley]

That doesn't work unfortunately. This is currently the Edit table for ALJobs:

generic object: ALJobList
table: x.table
rows: x
columns:
  - Title: |
      row_item.source
  - Employer: |
      row_item.employer.name if hasattr(row_item.employer.name, "first") else ""
  - Annual Income: |
      currency(row_item.gross_total())
edit:
  - source
  - employer.name.first
  - value
confirm: True

If we add - complete, the complete attribute, at the beginning of the edit: list, the only thing that happens is that it re-runs the code block that sets complete, which I think it just gets through without exception, since all of the other values are already set. You end up at the same screen with the same issue, and the complete variable is still set to true. There's no way to reconsider the complete attribute for the list items and all of their other values at the same time from the table that I can tell.

[plocket]

Is there a way to tell where the question is being triggered from? Something in the url args?

Tangentially, do any AL review questions have this problem? If not, they might in the future as we've mentioned wanting to list previous answers when we're collecting items.

[BryceStevenWilley]

Is there a way to tell where the question is being triggered from? Something in the url args?

No, I don't think so, not as a formal API, and I wouldn't trust any informal information we get from docassemble to be stable.

do any AL review questions have this problem?

Yes, I think this is likely happening in AL core too, mentioned at the bottom of the issue description:

Needs to go in several places though, in this repo and maybe in docassemble-AssemblyLine as well.