search

SuffolkLITLab / docassemble-AssemblyLine

Quickly go from a paper court form to a runnable, guided, step-by-step web application powered by Docassemble. Swap out branding and pre-built questions to meet your needs.
https://suffolklitlab.org/docassemble-AssemblyLine-documentation/
MIT License
41 stars 5 forks source link

Include AssemblyLine through interview list #784

Closed BryceStevenWilley closed 11 months ago

BryceStevenWilley commented 11 months ago

At MLH, we make a interview_list wrapper recently, that just included our interview framework YAML and interview_list.yml.

However, in doing so, al_audio.js is added twice to the page twice, and runs twice, so there are two Voice RSS widgets that show up, and one of them doesn't properly work (since it has the same id as the first).

IMO, interview_list.yml should just use AssemblyLine fully, instead of the awkward half-includes that it currently does. The only changes that happen when you do so are the red pre debug text and the footer, both of which I manually set to empty. People are welcome to re-enable those on interview_list if they wish.

I'm working an a PR to stop the JS stuff from running twice, even if it's on the page twice, still in progress there.

Downstream issue: https://github.com/mplp/docassemble-mlhframework/issues/15

BryceStevenWilley commented 11 months ago

A key design goal is that someone shouldn't have to customize this page or any server settings to have a default that is a drop-in replacement for the normal interview list page.

I'm okay with that, I didn't realize that was the case, given it's in AssemblyLine and not ALToolbox, and given how it's implemented now. When interview_list.yml loads, it defines / gets the default definitions of:

Agreed that an epic for stuff like this would be a good idea. #785 fixes the downstream issue independently as well, so we can it you want.

I can describe the things that need to be tested before it can be merged [before you start designing a solution so it's not just my feedback on a PR]

Sorry, I do kinda shoot off the hip with PRs sometimes. This one wasn't really designing a solution as much as it was diagnosing that it was the issue in the first place, and most things that seem like bugs and not design decisions I will make quick PRs for.

nonprofittechy commented 11 months ago

A key design goal is that someone shouldn't have to customize this page or any server settings to have a default that is a drop-in replacement for the normal interview list page.

I'm okay with that, I didn't realize that was the case, given it's in AssemblyLine and not ALToolbox, and given how it's implemented now. When interview_list.yml loads, it defines / gets the default definitions of:

* `AL_ORGANIZATION_HOMEPAGE` (the "Start a new form" button leads to it)

* `AL_ORGANIZATION_TITLE` (still set in the default parts of `interview_list.yml`

* `al_logo` (also still set in default parts)

Ah, I guess it does more than I thought. I couldn't think of a way around the AL_ORGANIZATION_HOMEPAGE but it does default to /list. We could probably get rid of the logo and title.

I can describe the things that need to be tested before it can be merged [before you start designing a solution so it's not just my feedback on a PR]

Sorry, I do kinda shoot off the hip with PRs sometimes. This one wasn't really designing a solution as much as it was diagnosing that it was the issue in the first place, and most things that seem like bugs and not design decisions I will make quick PRs for.

No worries there--if we check-in before big stuff that's good enough for me. I just feel bad shooting down an idea when it's already in a PR.