Task Template

Name: [main app] short description

Pad:

{description for the release note}

=====
LINKS
=====

Community
---------

PR:
Compare:
Branch:

Enterprise
----------

PR:
Compare:
Branch:

=======
PURPOSE
=======

Why did I create this task ?
What will this feature do ?
Which behavior would we like to support ?

==============
SPECIFICATIONS
==============

What needs to be done.
Mockups if any.

============
SIDE EFFECTS
============

What will this change imply in other modules ?
No code, only some hints of what you will do.

=========
MIGRATION
=========

Could this task impact the migration ?
Any advice for migration team ? (e.g. field value conversion, extra configuration steps)
Any business or functional advice for customers ?

=============
TESTING INDIA
=============

Date + comments in bullet points.

=======
HISTORY
=======

History of the specs.

Before you start...

Ask yourself :

• What is the purpose (added value) of the task ?
• Would a non-educated person be able to use what you are developing ?
• Is this button/field/feature necessary ?
• Do I understand all the specs ? Make sure that you and the PO are on the same page.

Consider possible cases :

• Multi-companies and multi-currencies
• Access rights
• Interactions between modules
• Timezones
• Customer portal

Think global :

• Cultural differences
• Country laws (e.g. sale prices: tax included or excluded)

Anticipate :

• Technical issues
• Side effects

Demo data

The new apps/feature must be tested and adding some demo data is good to help the user understand the application.

Demo data must be:

• diverse (e.g. in a kanban, split them between stages).
• coherent (e.g. if an opportunity is in negotiation, it must be linked to a customer and have a history).
• complete (e.g. a partner is not just a name, it's a logo, an address, ...).

Development Checklist

A. Main app

An application is a feature that has its own business score. It depends on no other feature. It corresponds to a particular need. For instance: I need an application to sell products.

• Choose a pertinent business name.
• Select 2-3 keywords to describe the application .
• To be available as an app, the application key must be set to True in __manifest__.py.
• Select a category (generally corresponding to main menu, main application)
• Describe the feature in the manifest.
• Link an icon.

B. Features/Options setup

Available from the settings, the option is a specific feature of a main application (e.g. multiple locations in warehouse management). The option will add a feature or some fields to the main application. It is business oriented.

• Include it in an existing separator/label (e.g: in Sales/Settings: "Quotations & Sales" is a separator).
• Use radio buttons to force the user to read and understand the impact of the choice (e.g: Use the same invoicing and shipping address vs. Display customer, invoice address and delivery address fields on sales orders).
• 1 radio button = 1 pertinent label.
• Does it need a configuration ? (e.g. Google Calendar)
  • For external apps, link to the documentation.
  • Add fields to fill inline.

C. Onboarding

The Application must be directly usable, and easy to use. Guide the user a maximum to help him through first clicks to achieve a business flow.

• Use American English.
• Jump to the right menu. Exception: if the action calls a wizard (avoid it when possible).
• Use tips to explain to the user what to do.
• The next step should be highlighted (e.g. In the Inventory dashboard, only one button is available. The others are hidden in the menu or in the "more" button of the card).
• In each app, there should be 3 or 4 menus.
• Every important feature should be available from the menu or the dashboard.
• In list views, show the main columns.
• The form view should be as close as possible to the real business document (e.g. a sale order).
• Use as few fields as possible. Use tools to hide fields.
  • Option in settings for advanced features.
  • Debug group (base.group_no_one) for technical features.
  • Tabs for secondary but useful fields.
  • Default values when possible (account, stock location, ...).
• Highlight the next step (e.g. "Save" button).
• Addresses must be displayed on 3 lines in form view.
• In form view, highlight the next step.
• Use stat buttons to jump to the screen of another model (e.g. Invoices of a sales order).
• Stage = process = kanban view.
• In kanban, show the tags with color.
• In kanban, show overdue activities in red.
• Show main information and clickable widgets (star, kanban-sate).
• If possible, the end of the flow should lead to feedback (e.g. 👍 once an opportunity is won, a congrats text when the inbox is empty, ...).
• Create demo data.

D. Configuration

The configuration must be minimalist.

• Use dropdowns to quickly add information (contacts, tags, …).
• Create a model only if fits up to 95% of business needs (stage, survey, …).
• Allow to create new records on-the-fly in m2o views if there are only a few columns.
• Use capital letters for each word in labels (except "in", "of", ...).
• Don't forget the domain on m2o. (e.g. the check of an access rights on user).