The first choice when developing a widget is to choose the correct base class. The fundamental base class for widgets is Widget (defined by web.Widget), but we didn’t choose it because it’s too basic. It only takes care of handling events and rendering, but we want more functionality for free. Still, this is an interesting class to study if you want to dig into Odoo’s JavaScript internals.

We chose AbstractField (defined by web.AbstractField) because it brings all the functionality we need for our widget to behave as a field. It does this by inheriting from Widget, which includes things such as communicating with the parent form and saving the current field’s value. You should study both classes, but the most important functions are overridden in the code example to make this widget do anything in the first place.

The init function should be used to do synchronous initialization tasks. Then, for asynchronous initialization, either use willStart (runs before rendering) or start (runs after rendering). Both these functions are supposed to return a deferred object, which can simply be obtained from super.

We use init to set up a list of users (this is only to keep it simple for now; generally,
hard-coded data is a horrible idea, of course). We’ll fix this in the Making RPC calls to the server recipe and to bind an event. Another possibility for binding events is using the mapping events, where you map an event name, possibly followed by a jQuery selector, to a function name. We use this to have click events for the buttons we create later set up automatically. For events that the Odoo framework provides, use the mapping custom_events.

The actual UI is created in _render, where we simply create one button per user, and mark the appropriate button with the btn_primary class. The _button_clicked event handler is then necessary to implement our widget’s behavior, that is, select the user a button displays, but don’t allow selections in read-only mode.

After we’ve defined our new widget, it’s crucial to register it with the form widget registry, which lives in web.field_registry. Note that all view types look at this registry, so if you want to create another way of displaying a field in a list view, you also add your widget here and set the widget attribute on the field in the view definition.

Finally, we export our widget class so that other addons can extend it or inherit from it.

The rest of the code is some quite unspectacular styling for our buttons, registering our JavaScript and CSS files with the system, and using our widget on the partner form.