The code in this recipe defines a few methods. They are normal Python methods that have self as their first argument, and can have additional arguments as well. The methods are decorated with decorators from the odoo.api module.

When writing a new method, you will generally use @api.multi. This decorator indicates that the method is meant to be executed on a recordset. In such methods, self is a recordset that can refer to an arbitrary number of database records (this includes empty recordsets), and the code will often loop over the records in self to do something on each individual record.

The @api.model decorator is similar, but it's used on methods for which only the model is important, not the contents of the recordset, which is not acted upon by the method. The concept is similar to Python's @classmethod decorator.

In step 1, we created the is_allowed_transition() method. The purpose of this method is to verify whether a transition from one state to another is valid or not. The tuples in the allowed list are the available transitions. For example, we don't want to allow a transition from lost to borrow, which is why we haven't put ('lost, 'borrowed').

In step 2, we created the change_state() method. The purpose of this method is to change the status of the book. When this method is called, it changes the status of the book to the state given by the new_state parameter. It only changes the book status if the transition is allowed. We used a for loop here because we used the @api.multi decorator and it can handle multiple recordsets.

In step 3, we created the methods that change the state of the book by calling the change_state() method. In our case, this method will be triggered by the buttons that were added to the user interface.

In step 4, we added the <button> in <form> view. On a click of these buttons, the Odoo web client will invoke the Python function mentioned in the name attribute. Refer to the Adding buttons to form recipe in Chapter 10, Backend Views, to learn how to call such a method from the user interface.

When the user clicks on the button from the user interface, one of the methods from step 3 will be called. self is a (possibly empty) recordset that contains the records of the library.book model. After that, we call the change_state() method and pass the appropriate parameter based on the button that was clicked.

When change_state() is called, self is the same recordset of the library.book model. The body of the change_state() method loops over self to process each book in the recordset. Looping on self looks strange at first, but you will get used to this pattern very quickly.

Inside the loop, change_state() calls is_allowed_transition(). The call is made using the book local variable, but it can be made on any recordset for the library.book model, including, for example, self, since is_allowed_transition() is decorated with @api.model. If the transition is allowed, change_state() assigns the new state to the book by assigning a value to the attribute of the recordset. This is only valid on recordsets of a length of 1, which is guaranteed to be the case when iterating over self.