Advanced settings in JSON

With Settings > Advanced, administrators can configure site operation by modifying a JSON specification. Advanced users can copy settings from one conference to another and configure aspects of the site not accessible via the normal settings UI.

View settings

Settings > Advanced shows the full site configuration as an object with dozens of components, including some settings unavailable elsewhere in the settings UI. Click on a component to get more information about that setting’s meaning and format.

Modify settings

To modify the site configuration, edit the provided JSON and save changes. Errors will be highlighted.

Any settings not mentioned in the JSON will keep their original values. For instance, to update a site’s submission fields and leave everything else the same, you could save a JSON object with just the sf component.

Object lists for complex settings

Settings including review rounds review, submission fields sf, review fields rf, and decision types decision are specified as object lists, which are arrays of JSON objects where each object corresponds to a subsetting. For instance, sf is an array with one entry per submission field, and decision is an array with one entry per decision type. The default decision setting looks like this:

{
    "decision": [
        { "id": 1, "name": "Accepted", "category": "accept" },
        { "id": -1, "name": "Rejected", "category": "reject" }
    ]
}
  • IDs. Individual objects in most lists are identified by their "id" components. The "id" is assigned by HotCRP and should not be changed. If a subsetting is missing its "id", HotCRP searches existing subsettings for one with a matching "name"; if none is found, the subsetting is assumed to be new.

  • Adding subsettings. "id": "new" identifies subsettings that should be added. For instance, this adds two new decision types:

    {
        "decision": [
            {"id": "new", "name": "Desk reject", "category": "desk_reject"},
            {"id": "new", "name": "Desk accept", "category": "accept"}
        ]
    }
  • Deleting subsettings. Delete a subsetting by adding "delete": true to its object. For instance, this would delete a “Desk reject” decision:

    {
        "decision": [
            {"name": "Desk reject", "delete": true}
        ]
    }
  • Resetting subsettings. Unmentioned subsettings are left unchanged by default. If you want instead to delete any unmentioned subsettings, set "reset" or "SETTINGNAME_reset" to true. For instance, this deletes all topics:

    {
        "topic_reset": true, "topic": []
    }

    This, on the other hand, has no effect (the JSON mentions no topics, so all topic subsettings remain unchanged):

    {
        "topic": []
    }
  • Copying settings between conferences. Beware of IDs when copying settings between conferences. Unless you are careful, the IDs used in one conference may differ from the IDs in another. Consider removing the IDs from a conference’s JSON settings before uploading those settings to another conference.

  • Other common components in object lists include "order", which determines the natural order for subsettings (e.g., the order submission fields appear on the submission form; lower values appear first), and "values", a nested object list that determines the values that apply to a submission or review field.