• 
      

    Add a guide for writing custom review request conditions.

    Review Request #15071 — Created May 21, 2026 and submitted

    Information

    Review Board
    release-8.x

    Reviewers

    This is a complete guide for writing custom review request conditions,
    used for integrations and in the future other parts of the UI.

    It starts off with an education of what conditions are for and the main
    components, and then walks through the types of condition choices and
    customization options, the operators and customization for those, and
    then working with value fields, followed by how to register condition
    choices.

    Built the docs. Checked for any obvious build or spelling errors.

    Ran it through Claude to check for any code or writing issues.

    Summary ID
    Add a guide for writing custom review request conditions.
    This is a complete guide for writing custom review request conditions, used for integrations and in the future other parts of the UI. It starts off with an education of what conditions are for and the main components, and then walks through the types of condition choices and customization options, the operators and customization for those, and then working with value fields, followed by how to register condition choices.
    833c3ed033435cd655a7b08e6f4486ba9265a4fd
    Description From Last Updated

    Typo: trying to matching -> trying to match

    david david

    I notice in other examples, you got rid of the gettext wrapping.

    maubin maubin

    This is missing a : Also, other similar lists in this doc are using paragraph mode (blank line between term …

    david david

    We haven't seen this before, we see it below.

    maubin maubin

    Can we put in a type hint for the generic here too (like we do in review-request-condition-choices-hook.rst) ?

    david david

    Wrapping is a little funky here.

    david david

    These are actually the same as Any/None, just renamed in this class. We should get rid of this line.

    david david

    This should be in an if TYPE_CHECKING block. Same for other examples in this change.

    david david

    One too many ===s here

    david david
    maubin
    1. 
        
    2. Show all issues

      I notice in other examples, you got rid of the gettext wrapping.

      1. Yeah, for got to nuke these ones. It's because extensions, even if they use gettext, can't really add to our localizations.

    3. Show all issues

      We haven't seen this before, we see it below.

      1. Ah good catch. Fallout from moving sections around.

    4. 
        
    david
    1. 
        
    2. Show all issues

      Typo: trying to matching -> trying to match

    3. Show all issues

      This is missing a :

      Also, other similar lists in this doc are using paragraph mode (blank line between term and definition). We might want to do that here.

    4. Show all issues

      Can we put in a type hint for the generic here too (like we do in review-request-condition-choices-hook.rst) ?

    5. 
        
    chipx86
    david
    1. 
        
    2. docs/manual/extending/extensions/condition-choices.rst (Diff revision 2)
       
       
       
       
       
       
      Show all issues

      Wrapping is a little funky here.

    3. Show all issues

      These are actually the same as Any/None, just renamed in this class. We should get rid of this line.

    4. Show all issues

      This should be in an if TYPE_CHECKING block. Same for other examples in this change.

      1. I've been erring on the side of keeping the code concise and not having to explain the TYPE_CHECKING stuff. My thought was, concise examples highlighting what we're showing off is important, and TYPE_CHECKING is something that is non-obvious and optional.

        The average IT team working on an extension isn't going to be affected by importing things only used for typing from our codebase at runtime. If they don't understand TYPE_CHECKING and put something there and then end up needing it, there's going to be confusion.

        The more advanced Python developer with understand all this and have their own approach to either importing as-is or importing into a TYPE_CHECKING. They won't just be copying/pasting our code whole-sale.

      2. Sounds fine.

    5. Show all issues

      One too many ===s here

    6. 
        
    chipx86
    david
    1. 
        
    2. 
        
    maubin
    1. Ship It!
    2. 
        
    chipx86
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to release-8.x (f5d80d0)