Settings & Configuration

Scheduled Actions

Scheduled actions (also called cron jobs) run automated tasks on a repeating schedule. They handle periodic maintenance, data processing, and automated communications.

Navigation

Go to Settings > Technical > Scheduled Actions (developer mode required).

Important System Scheduled Actions

Creating a Custom Scheduled Action

1. Click Create.
2. Name – e.g. "Daily Sales Summary Email".
3. Model – The model the action works on (most system actions use ir.actions.server).
4. Execution Frequency:
• Number of Calls – Run a fixed number of times, then stop.
• Do Not Repeat – Run once.
• Repeat Every – Run on a recurring schedule. Specify interval (Minutes, Hours, Days, Weeks, Months).
5. Next Execution Date – When to run first. Use a future date/time.
6. Number of Calls Remaining – For repeating actions, this decreases each run. Set to -1 for unlimited runs.
7. Under Server Action to Run, select the action that executes when the cron fires.
8. Check Active to enable the cron.
9. Click Save.

Cron Monitoring

The list view of scheduled actions shows:

• Status – "Done", "Running", or "Failed". Red background indicates a failure.
• Last Execution – Timestamp of the last run.
• Next Execution – When the next run is scheduled.
• Progress – For long-running crons, shows progress information.

If a cron fails, click the failed status to see the error details in the server logs. Common causes: Python errors in the action, unavailable network resources, or database locks.

Best Practices

• Schedule heavy operations during off-peak hours (e.g. 2:00 AM).
• Avoid running crons too frequently – a "Repeat Every 1 Minute" cron that takes 30 seconds may overlap with itself if it starts a second instance before the first finishes. Quickenerp prevents this by checking that the previous instance has completed before starting a new one.
• Test new crons by setting "Number of Calls" to 1 and a "Next Execution" of 2 minutes from now, then verify it runs correctly before making it recurring.

Incoming Mail Server Configuration

An incoming mail server allows Quickenerp to:

• Receive replies to emails and append them to the correct record's chatter.
• Create new records from incoming emails (e.g. a new lead from a website contact form).
• Route emails to Discuss channels via aliases.

Navigation

Go to Settings > Technical > Incoming Mail Servers (requires developer mode).

Creating an Incoming Mail Server

1. Click Create.
2. Name – A label (e.g. "General Inbox – IMAP").
3. Server Type – Choose IMAP (recommended) or POP. IMAP is preferred because it keeps emails on the server and syncs state. POP downloads and deletes by default.
4. Server Name – e.g. imap.gmail.com for Gmail.
5. Port – 993 for IMAP SSL, 995 for POP SSL, 143 for IMAP STARTTLS.
6. SSL/TLS – Enable for secure connections.
7. Username – Full email address.
8. Password – Email password or App Password.
9. Under Actions to Perform on Incoming Emails, you can define rules that process incoming emails automatically:
• Create a New Record – e.g. create a Lead from an email to sales@company.com.
• Find Existing Records by Email Address – e.g. match the sender email to an existing contact.
• Thread into Existing Chatter – Link the email to the record.
10. Click Save. The server starts checking for new emails every 5 minutes via a cron job.

Email Aliases

Email aliases allow you to create special-purpose email addresses that route to specific functions:

Configure aliases in each module's settings. For example, CRM alias is in CRM > Configuration > Settings.

Troubleshooting Incoming Mail

• Emails not being fetched – Check the "Fetchmail: Retrieve Incoming Mail" scheduled action is active.
• Emails fetched but not acted on – Review the action rules on the incoming server. Check the server logs for errors.
• Authentication errors – Verify the password/App Password. Gmail App Passwords expire rarely but may need regeneration.
• Duplicate processing – IMAP is safer than POP. POP deletes emails after fetching, which can cause issues if multiple servers process the same mailbox.

Developer Mode

Developer mode (also known as debug mode) unlocks advanced technical features that are hidden from regular users. It is essential for system administrators who need to customise forms, create automated rules, inspect system data, or configure security.

How to Enable Developer Mode

There are three ways to enable it:

1. From Settings: Go to Settings > General Settings, scroll to the bottom of the page, and click Activate Developer Mode (wrench/spanner icon). The page reloads with developer features visible.
2. URL Parameter: Add ?debug=1 to any URL. Example: https://quickenerp.com/web?debug=1. This enables developer mode for your session.
3. Developer Tools (Assets): Add ?debug=assets to enable developer mode with unminified JavaScript/CSS assets. This is useful for debugging UI issues but the page loads slower.

What Developer Mode Adds

1. Technical Menu

A new top-level Technical menu appears (in Settings or as a standalone menu). It contains:

2. Edit View Option

On any form view, the Actions (gear) menu now includes Edit View. This opens the XML view definition, letting you:

• Add or rearrange fields in the form layout.
• Modify field attributes (readonly, required, invisible).
• Add custom buttons and logic.
• Changes apply immediately. No deployment or restart needed.

3. Field Tracking Configuration

Tracked fields show a history of changes in the chatter – who changed what and when. Enable tracking on any field from the field configuration in Technical – Fields.

4. Additional Context Menu Options

Right-clicking on many elements shows developer options:

• Inspect View – Shows the view architecture and technical IDs.
• View Metadata – Shows record metadata (External ID, model name, creation/modification details).
• Manage Fields – Opens the field configuration for the current model.

Caution

Developer mode gives access to settings that can break the system if misconfigured. Follow these rules:

• Only enable developer mode when you need to make technical changes.
• Disable it when you are done (click the "Deactivate Developer Mode" link at the bottom of General Settings).
• Never modify views or security rules unless you fully understand the implications.
• Take screenshots of default values before changing them.
• Test changes in a staging environment first (if available).