Add a central registry and hooks for custom condition choices.

 






 

 


  Review Request #14280
  —
  Created Jan. 1, 2025 and updated 

 




















 

  

   Information

  





 
 

  chipx86
 









 
 

  Review Board
 









 
 

  release-7.1.x
 









 
 

  
 









 
 

  
 









 
 

  14281
 






 




 

  

   Reviewers

  





 
 

  reviewboard
 









 
 

  
 






 








 





  


 
 

  
When we first wrote the support for condition choices for integrations,

we intended for the framework to be extensible, allowing extensions to

produce new condition choices that users could select from. However,

this didn't work in practice, since we lacked any kind of central

registry for condition choices that extensions could hook into.


This change introduces a new central review_request_condition_choices

registry, along with a new ReviewRequestConditionChoicesHook that

wraps it.


A central ReviewRequestConditionsField can be used whenever a

ConditionsField is meant to be used with review_request_condition_choices,

enabling custom condition choices from any extension. rbintegrations 4.1

will be updated to use this.


Documentation has been written to help extension authors make use of the

new hook. It only touches upon the basics of creating new choices, and

doesn't touch upon custom operators, but it should be enough to get

people going.

 








  


 
 

  
Unit tests passed.


Tested the new central registry with in-progress code in rbintegrations

and Power Pack.


Built the docs. Checked the example code against the unit tests, and

checked for bad links and other errors.

 







 









 





  

 


 
 

  



 

  
   


    Summary
    ID

   

  
  

   


    

     

      Add a central registry and hooks for custom condition choices.
      
When we first wrote the support for condition choices for integrations,
we intended for the framework to be extensible, allowing extensions to
produce new condition choices that users could select from. However,
this didn't work in practice, since we lacked any kind of central
registry for condition choices that extensions could hook into.

This change introduces a new central `review_request_condition_choices`
registry, along with a new `ReviewRequestConditionChoicesHook` that
wraps it.

With this, any extension can easily introduce one or more new condition
choices, which will be picked up automatically when presenting a
`ConditionsField` (when used along with the upcoming rbintegrations
4.1 release).

Documentation has been written to help extension authors make use of the
new hook. It only touches upon the basics of creating new choices, and
doesn't touch upon custom operators, but it should be enough to get
people going.

     


    		
    9451fe1c2a3b17921c97ee4cb3d2d58754680aa3

   



  
 




 













 






 
 
 

  

   

    

     
    

    
    
     
  • 
      
     
    • 
     
  • 
      
     
    • 
     
  • 
      
     
    • 
     
  • 
      
     
    • 
     
  • 
      
     
    • 
    

   

   

    
     

      Description
      From
      Last Updated
     

    
    



     

      
       
       
'reviewboard.extensions.base.Extension' imported but unused Column: 1 Error code: F401

      		
      
       reviewbotreviewbot
      
      
       
      
     




     

      
       
       
Should we include type hints in this example?

      		
      
       daviddavid
      
      
       
      
     




     

      
       
       
In order to make some linters happier about the lack of docstrings, can we preface this with _?

      		
      
       daviddavid
      
      
       
      
     




     

      
       
       
Same here.

      		
      
       daviddavid
      
      
       
      
     




     

      
       
       
This needs to be alphabetized.

      		
      
       daviddavid
      
      
       
      
     


    
   

  

 







 






  

 



















 




 

  


   

   

    
 
Checks run (1 failed, 1 succeeded)


    
   


  

  

  





 

 flake8
 failed.
 





 

 JSHint
 passed.
 













 
flake8

 


 










  

 





 














 



 

  

   




chipx86




   

   

  

 



 

  


   

   

    
 Review request changed

    
   


  

  

  









  

   

    Change Summary:
   

   

    
Removed an unused import.

   

  








  

   

    Commits:
   

   

    





 

  
   


    

    Summary
    ID

   

  
  

   


    

    

     

      Add a central registry and hooks for custom condition choices.
      
When we first wrote the support for condition choices for integrations,
we intended for the framework to be extensible, allowing extensions to
produce new condition choices that users could select from. However,
this didn't work in practice, since we lacked any kind of central
registry for condition choices that extensions could hook into.

This change introduces a new central `review_request_condition_choices`
registry, along with a new `ReviewRequestConditionChoicesHook` that
wraps it.

With this, any extension can easily introduce one or more new condition
choices, which will be picked up automatically when presenting a
`ConditionsField` (when used along with the upcoming rbintegrations
4.1 release).

Documentation has been written to help extension authors make use of the
new hook. It only touches upon the basics of creating new choices, and
doesn't touch upon custom operators, but it should be enough to get
people going.

     


    		
    edcffe03efc09593aafe2ecd22c157d25fbd40d7

   




   


    

    

     

      Add a central registry and hooks for custom condition choices.
      
When we first wrote the support for condition choices for integrations,
we intended for the framework to be extensible, allowing extensions to
produce new condition choices that users could select from. However,
this didn't work in practice, since we lacked any kind of central
registry for condition choices that extensions could hook into.

This change introduces a new central `review_request_condition_choices`
registry, along with a new `ReviewRequestConditionChoicesHook` that
wraps it.

With this, any extension can easily introduce one or more new condition
choices, which will be picked up automatically when presenting a
`ConditionsField` (when used along with the upcoming rbintegrations
4.1 release).

Documentation has been written to help extension authors make use of the
new hook. It only touches upon the basics of creating new choices, and
doesn't touch upon custom operators, but it should be enough to get
people going.

     


    		
    9451fe1c2a3b17921c97ee4cb3d2d58754680aa3

   



  
 







   

  





  

   

    Diff:
   

   

    
 Revision 2 (+740 -6)
Show changes
 
    docs/manual/extending/index.rst 
    docs/manual/extending/extensions/hooks/index.rst 
    docs/manual/extending/extensions/hooks/review-request-condition-choices-hook.rst 
    reviewboard/extensions/hooks/__init__.py 
    reviewboard/extensions/hooks/conditions.py 
    reviewboard/extensions/tests/test_review_request_condition_choices_hook.py 
    reviewboard/reviews/conditions.py 
    reviewboard/reviews/forms.py 
 

   

  











 

  
Checks run (2 succeeded)



  

 flake8
 passed.
 





  

 JSHint
 passed.
 





 















  

 
















 





 

  

   




david




   

   







  

 



 

  


   

   

    
 
david


    
   


  

  

  



    




  1. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 

















  2. 
 
    
  
  
    
  
 
    
  
    
   
    
    
     
    
      
       docs/manual/extending/extensions/hooks/review-request-condition-choices-hook.rst
       


        (Diff revision 2)


       
      
     
    
        
    
     
     
    

     
     
    

     
     
    

     
     
    

        
   
    
  
    
 
    

   
    
    
    




    
 
    
  
  
  

  
  
   Show all issues
  
 
    

    



    
    Should we include type hints in this example?
    
  
    
 
    

 
    
  


    
 
    
 
      

  


    1. 
 
 
      
 
      
  
 
      
 
      
  
      I've been leaving them out just to keep the examples simple. I figure most people who are doing development probably aren't going to be writing type hints (largely IT and such), and they should still be inheriting the types from the parent methods anyway.
      
 
      

      2. 


 
    


    

 
    

    3. 






  3. 
 
    
  
  
    
  
 
    
  
    
   
    
    
     
    
      
       reviewboard/extensions/tests/test_review_request_condition_choices_hook.py
       


        (Diff revision 2)


       
      
     
    
        
    
     
     
    

     
     
    

        
   
    
  
    
 
    

   
    
    
    




    
 
    
  
  
  

  
  
   Show all issues
  
 
    

    



    
    In order to make some linters happier about the lack of docstrings, can we preface this with _?
    
  
    
 
    

 
    
  


    
 
    
 
      

  


    1. 
 
 
      
 
      
  
 
      
 
      
  
      Which linters have this rule? I haven't seen this. We should standardize any linting tools we're using.
      
 
      

      2. 


 
    


    

 
    

    4. 






  4. 
 
    
  
  
    
  
 
    
  
    
   
    
    
     
    
      
       reviewboard/extensions/tests/test_review_request_condition_choices_hook.py
       


        (Diff revision 2)


       
      
     
    
        
    
     
     
    

     
     
    

        
   
    
  
    
 
    

   
    
    
    




    
 
    
  
  
  

  
  
   Show all issues
  
 
    

    



    
    Same here.
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    5. 






  5. 
 
    
  
  
    
  
 
    
  
    
   
    
    
     
    
      
       reviewboard/reviews/forms.py
       


        (Diff revision 2)


       
      
     
    
        
    
     
     
    

     
     
    

        
   
    
  
    
 
    

   
    
    
    




    
 
    
  
  
  

  
  
   Show all issues
  
 
    

    



    
    This needs to be alphabetized.
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    6. 




  6. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    7.