Skip to main content

Disable Quick Create

Purpose​

Disable Quick Create lets administrators control whether users can create a related record from a field, choose Create and Edit, or open and edit a linked record. A rule can cover a target model throughout supported fields or apply to one source field, with optional user, group, company, and date restrictions.

These controls govern supported form widgets. Native model permissions and record rules still decide who can read, create, or change records. Use this module to simplify the choices offered in a field; use Odoo access rights to protect the underlying records.

Before you start​

Install the package matching your exact Odoo major version. The reviewed 19.0 manifest depends on Web (web) and Partner Autocomplete (partner_autocomplete), with no Enterprise-only dependency declared. This guide describes the 19.0 source-defined workflow; no runtime test was performed.

Identify the target model and, for a field-specific rule, its source model and relational field. The field must be a many-to-one or many-to-many relation pointing to that target. A model-wide rule leaves both source selections empty; a field-specific rule requires both.

Access and roles​

Only a System Administrator can manage rules or use the simulator. Rules can be global or company-specific; administrators can access rules for their allowed companies and must activate a rule's company before modifying it.

Rules may target one user or one group, but cannot specify both. A targeted user's allowed companies must include the selected company. Ordinary internal users receive the resolved restrictions without access to rule configuration. The service excludes portal and shared users.

Setup and menu​

In the Settings technical menus, open Quick-Create Governance. The same area provides Rule Simulator and Rule Coverage. The Settings page also contains Quick-Create Governance → User Explanation, where the administrator controls restriction hints and the default restriction message.

Each rule has four independent choices: Allow Quick Create, Allow Create and Edit, Allow Opening Linked Records, and Allow Editing Linked Records. They start enabled. Clear the actions you want to restrict and optionally write a concise explanation for users.

When several rules match, one rule wins. A field-specific rule takes precedence over a model-wide rule. Within that scope, user rules rank above group rules, then company rules, then global rules. Company specificity and higher priority further resolve matches; an earlier rule breaks a remaining tie. Restrictions from several matching rules are not combined. Use the simulator to inspect the actual winner before rollout.

Workflow​

  1. Create a rule. Give it a descriptive name and select Target Model. For one particular field, select its Source Model and Source Field as well. Save only after checking that the relation points to the intended target.
  2. Set the audience and dates. Select a user, a group, or neither. Choose a company when the rule should apply only there. Set Valid From and Valid Through if needed; the end date cannot precede the start date.
  3. Choose the allowed actions. For example, clear Allow Quick Create while leaving Allow Create and Edit enabled when users should complete the full form for a new related record. Existing native restrictions continue to apply even when a rule allows an action.
  4. Run Rule Simulator. Select the intended user, company, source model, source field, and date. Review the matched rule and the eligibility and precedence explanation. The simulator checks policy selection; it is not a substitute for checking that user's native record permissions.
  5. Check the supported field as an authorized test user. Reopen or refocus the form after saving the rule. Confirm that the intended choices are absent or available and that any restriction explanation is appropriate. The client refreshes its policy version on refocus.
  6. Review Rule Coverage. Inspect broad rules and field-specific exceptions together. Archive a rule when it should stop applying, then repeat the simulator check for affected users.

Practice scenario​

In an authorized test database, fictional company Northstar wants staff to select existing contacts from one relational field without creating incomplete contacts there. Choose an existing supported field that points to Contacts, create a rule for that field and the test staff group, and disable quick creation and Create and Edit. Leave opening and editing enabled. Simulate the staff user and then inspect the field under that user's account. The source-derived expected outcome is that creation choices disappear while native permissions continue to govern existing contacts. This exercise has not been executed.

Troubleshooting and limitations​

  • The rule does not save: check the paired source selections, relation type, date order, and user/company combination.
  • A different rule applies: inspect field specificity before changing priority; a high-priority global rule does not outrank a field-specific rule.
  • An action remains unavailable: this module cannot grant an action already blocked by the view or native permissions. Supported widgets also disable governed actions while policy loading fails or is incomplete.
  • A custom field widget behaves differently: the reviewed client covers standard many-to-one, partner many-to-one, many-to-many tags, and form many-to-many tags widgets. Other custom widgets need separate verification. Editing a form tag requires the applicable opening and editing permissions; color editing follows the editing permission.
  • Creation is still possible elsewhere: imports, APIs, and separate record menus remain subject to native access controls. These rules are not a global ban on record creation.

The catalogue offers 15.0–20.0. The older packages use version-specific widget implementations, and 20.0 changes its access configuration; those complete workflows remain unreviewed here. Check the exact package and any custom relational widgets before deployment.

Live Test — Odoo 19 uses a qualified catalogue pair; no demo was launched for this review. For purchase, open the Corvus app catalogue and choose your exact version. Related: CRM Lead Qualification for governing lead readiness after data entry.