Customizing Forms
A guide for program chairs on how to customize the different forms available to the reviewing committee
Last updated
Was this helpful?
A guide for program chairs on how to customize the different forms available to the reviewing committee
Last updated
Was this helpful?
Many OpenReview forms are customizable from the different buttons on the venue request form. You can find where to input your customizations by clicking on a button (for example, "Review Stage") and finding the large text box under "Additional _____ Options". Under "Revision", you'll find that this box modifies the submission form under the heading "Additional Submission Options". For the "Review Stage", the heading will be "Additional Review Form Options"
Some buttons configure other parts of the workflow that do not have an associated form, in which case there will not be an additional options text box.
Whenever possible, forms should be customized through the venue request form following the directions above rather than editing an invitation directly - this saves your changes in the case that you update any other settings for your venue.
These text boxes accept a valid JSON object with fields and values. The following is an example where the title field gets replaced with a radio button, like so:
Note that correct indentation levels and matched brackets are necessary for valid JSON.
The primary fields of the entry are:
title - This will be the name of the field in the form
order - Determines where in the form the field will appear
description - Will show up in the form as instructions or description
value - Will have subfields (under param) determining the format of the field and the options for responses
When making a field that is asking for user input, you will always see this pattern of "value": { "param": {...} }. Inside the param object are fields determining what the user sees in the input form along with what the user is allowed to submit: these are representation specifiers and validation specifiers.
Both validation and representation specifiers can be found inside the param object
This section will introduce common specifiers used in customizing forms. Further information about specifiers can be found here.
Representation specifiers determine how the user will input their response into the field (for example a textbox or a checklist). These will be defined in the param object.
The input specifier determines the rendering on the form and can have the following values (see below for examples of how different input types render):
text
select
checkbox
textarea
radio
default is the default value of the box that will appear when the widget is initialized
markdown is a boolean value (true/false) that enables markdown for this text field
scroll is a boolean that adds a scroll bar to a textarea input
Validation specifiers are used by the back-end to ensure data submitted through the form conforms to certain requirements. In the example above, only a single string is allowed, and that string must be one of the values defined in the enum array. Specifically, a string that has the value "Test Submission Title"
optional is a boolean (true/false) value that indicates whether or not this field is required to be present when the form is submitted. By default all fields in the form are required, and you can add optional : true to indicate a required field.
Required fields have their field names prefixed with an asterisk
type specifiers require the input to be of a specific type: options are string, string[] (string array) and file.
string fields can be further validated by using fields to describe the structure of a valid string input. Some of these field are:
"maxLength": set the maximum number of characters of the input
"minLength":set the minimum number of characters of the input
"regex": use regular expressions to define acceptable string structures
"enum": restrict the user to a predefined set of strings
"items": an array of strings as indicated by its type (only used with type: string[] ) **
** All values in "items" will be considered required unless specified otherwise with "optional": true. Please see multiple choices for an example.
file fields are specifically validated with maxSize and extensions. maxSize is an integer that specifies the size of the largest file that can be uploaded on the form in megabytes. extensions is a list of strings that are extensions, for example "extensions": ["pdf", "zip"].
Extensions that have a "." in them are not supported. The following field would be invalid because "tar.gz" is not supported:
If you want to limit who in the committee can see a particular field in a form, this is done by adding a readers field. Please follow this link for more detailed information on hiding or revealing fields. Below are two examples, one for the submission form and one for the meta review form. Notice the different use of dollar sign notation. The notation used for the meta review form will also work for other replies to the forum: reviews, comments, and decisions.
