This page is very much under construction as we develop the weaver's capabilities. These 🚧 emoji notes features that are being actively developed in the Weaver and thus might change
This page breaks down what each of these "blocks" (the sections of text that appear between
do individually. You don't have to think about every block as you develop your interview, but as
you use more advanced features of docassemble, knowing more about these blocks
An include block incorporates content (code blocks, questions blocks, etc.) from other YAML files. When you run the interview, docassemble acts as if all of the content in the YAML files listed below was copied and pasted right in this exact spot. This is described in more detail in the docassemble documentation.
include block includes the AssemblyLine package, giving you access to all of the pre-created questions in AssemblyLine. It also adds the jurisdiction and organization packages that you picked in the Weaver. By default, the jurisdiction package is ALMassachusetts, and the organization package is the MassAccess package.
These metadata block values control two things:
- the text in this interview's browser tab
- the name of the interview on a user's list of saved interviews if they're logged in
You can explore some other settings that you can define here in the docassemble documentation.
The AssemblyLine metadata block has different, AssemblyLine specific metadata that doesn't fit in the normal metadata block. Additionally, data in this block isn't overwritten if it's included in another interview.
short title, and
descriptionallow your organization's site to show more information about your form and to organize your forms more easily.
original_formis simply a link to the original, fillable PDF form that this interview is automating, if it exists.
allowed courtsallows your code to decide which courts to let the user pick from when they need to pick their court, usually used in conjunction with AL Generic Jurisdiction.
categoriesis the LIST taxonomy code for this interview, which can be used by your organization to organize your interviews.
attachment block variableused to be used in the code that sends documents to courts, but now the ALDocument object block is used instead.
logic block variableshould also no longer be used.
typical role: controls which questions the user gets asked about themselves and other parties.
Adds this text to the organization's intro page that appears at the beginning of every interview. This lets your user know right away that they have gotten to the right (or wrong) form. Note that this can (and should) be a more direct and detailed call to action, e.g. ("File a ____" or "Ask the court for ____"), rather than a simple short title, like the short title in the metadata block.
Changes the wording of AssemblyLine questions depending on it's value. It can be either:
- a court-case type: 'starts_case', 'existing_case', or 'appeal'
- a letter: 'letter'
- other: 'other', 'other_form'
sections work with
nav.set_section() to show the column on the left that lets your users jump to a screen that lets them edit their information in your interview.
This helps users avoid using the 'Back' button which deletes their answers.
By default, there is a single "Review" section, that covers the whole interview. In longer interviews, adding more sections can show the user a roadmap of what they will have to do and where they are now.
Controls the order in which your screens are shown.
The full interview order block will look something like this. We'll go over each line individually below.
allowed_courtsallows the developer to limit which courts the person filling out the form can pick from, making it easier for them to pick the right court. By default, it's using the same values that are in the metadata block.
a_258e_motion_for_impoundment_introso that the user can't click to edit their answers before they've actually been asked any questions.
user_roletells AssemblyLine which questions to ask about the main party listed on the form. This should be the same as the
typical role. However, if
unknown, then the
user_ask_rolevariable will be here instead, and will ask the user what role they have in the case.
Code for your custom questions comes next. All your questions should be triggered in here. You will probably make major edits to the code here, changing the order and adding branching logic.
set_parts(subtitle=str(users))adds to the information a logged in user will see for this interview in their list of interviews. For an attorney, they should see the name of their clients. For a self represented litigant, they should see their name. You can read more about
set_partsin the docassemble documentation.
set_progress()changes the progress bar shown to the person who's interacting with the form. When they are at the beginning of the form, it should be empty. When they are at the end, other code will make sure it is full. The ALWeaver tries to handle intermediate values between those two places that will make sense to the user. The example interview is short, so intermediate progress is only set once.
- The final variable in the block (
interview_order_a_258e_motion_for_impoundmentabove) is customized for your interview. It lets you trigger all the code in this entire code block. In this generated code, the main order block triggers it. If you are including this interview in another interview, remove the main order block. Then you can use this variable if you want to trigger this particular question order.
This block controls the order of things that do not need to be customized for your specific interview, like intro screens, signatures, etc. You shouldn't have to change that code unless you are 🚧 combining multiple interviews together 🚧.
There is some AssemblyLine code that comes after your own custom interview order code. You will probably leave this code alone as well:
signature_dateis the date that the user signed the form, and is needed on every form that has a signature.
store_variables_snapshot()lets you gather data about this interview session. You should be very thoughtful about what you store, and care must be taken to anonymize it. Just removing a name is not sufficient.
If you want to avoid asking the user for their address, you will need to change the information you save here. This code forces the user's address to be asked.
a_258e_motion_for_impoundment_preview_questionwill trigger the preview screen.
basic_questions_signature_flowallows the user to pick what device to sign on. This lets them send the form to a smartphone for signing.
users.signatureshows the user the signature screen.
question blocks control the screens your clients will see that are specific to your interview.
Users can see the final form that they will then be signing before they sign it.
Question blocks will show screens with information and questions. You will probably edit these blocks as you identify your needs and the needs of the people using your tools.
Users will be able to download or email the form. They may sometimes be able to submit it to the court.
Leave this block as it is if possible. Prepares to use this document in the
Usually you need to make at least two different attachment blocks for a PDF: a preview without a signature and the final document with a signature. The ALDocument class takes care of that for you. It also contains some nice features like adding addendums if an interviewee's answers are too long.
Leave this block as it is if possible. Adds your file to two 'bundles' automatically - one for the user and one for the court.
The ALDocumentBundle class lets you combine files in different ways easily. For example, when sending a packet to the court you might want to add a cover page, but when sending one to the client you might want to include an instruction sheet instead. With the ALDocumentBundle class, this is as simple as adding the new attachment to the
elements parameter below.
An attachment block for a PDF. This is how you will put your user's answers into a PDF's fields. You will have one for every PDF in your form. Its name is based on your PDF file name.
The 'Back' button deletes answers as the user goes farther back. When they press to continue, they will have to fill in their answers again. The review screen lets them edit their answers without deleting any of them.
The code generated for this section is just a starting point. You will probably have to make changes to get what you need.
There might be additional blocks that start like
continue button field: users.revisit or
These blocks are used by the review screen to display and edit multiple pieces of information, like plaintiffs
and their contact information.