Command-line interface (CLI)¶

The CLI command-line interface offers several functionalities related to Odoo. You can use it to run the server, launch Odoo as a Python console environment, scaffold an Odoo module, populate a database or count the number of lines of code.

مهم

The command to use to call the CLI depends on how you installed Odoo. In the examples below, we assume that you are running Odoo from source with the odoo-bin file. If you installed Odoo from a distribution package or with Docker, you must adapt the command.

Navigate to the root of the directory where you downloaded the source files of Odoo Community.
Run all CLI commands with ./odoo-bin

When Odoo was installed, an executable named odoo was added to your user's PATH. Replace all occurrences of odoo-bin with odoo in the examples below.

نسخه¶

-h, --help¶

it can be used in combination with any command available, and it displays the options of the current command.

If no command is used, it will act as per the help command below.

--version¶: shows Odoo version e.g. "Odoo Server 19.0"

نکته

You can enable auto-completion in your shell by running

COMMANDS=$(odoo-bin --help | sed -e "s/^    \([^ ]\+\).*$/ \1/gp;d" | xargs)
echo "complete -W '$COMMANDS' odoo-bin" >> ~/.bash_completion

`help` - Show available commands¶

This command shows all the available commands for Odoo.

It has no options.

`server` - Run the Server¶

This command is the default one: you can omit it, and it will be chosen anyway.

-d <database>, --database <database>¶

database(s) used when installing or updating modules. Providing a comma-separated list restrict access to databases provided in list.

For advanced database options, take a look below.

-i <modules>, --init <modules>¶: comma-separated list of modules to install before running the server (requires -d).

-u <modules>, --update <modules>¶: comma-separated list of modules to update before running the server. Use all for all modules. (requires -d).

--reinit <modules>¶

A comma-separated list of modules to reinitialize before starting the server. (requires -d).

The reinitialization is similar to a simple upgrade without executing any upgrade script. It loads data in init mode instead of update mode, primarily affecting records marked as 'noupdate'. All modules that depend directly or indirectly on the specified ones will also be reinitialized.

این گزینه فقط برای اهداف اشکال‌زدایی یا توسعه در نظر گرفته شده است. از آن با یک پایگاه داده تولیدی استفاده نکنید.

--addons-path <directories>¶: فهرست جداشده با کاما از دایرکتوری‌هایی که ماژول‌ها در آن‌ها ذخیره می‌شوند. این دایرکتوری‌ها برای ماژول‌ها پیمایش می‌شوند.

--upgrade-path <upgrade_path>¶: فهرست جداشده با کاما از دایرکتوری‌هایی که اسکریپت‌های ارتقای اضافی از آن‌ها بارگذاری می‌شوند.

--pre-upgrade-scripts <pre_upgrade_scripts>¶: فهرست جداشده با کاما از مسیرهای اسکریپت‌های ارتقا. این اسکریپت‌ها پیش از بارگذاری ماژول base هنگام درخواست ارتقای هر ماژولی اجرا می‌شوند. این برای انجام برخی اقدامات در طول ارتقای ماژول‌های سفارشی پس از یک ارتقای بزرگ مفید است.

--load <modules>¶: فهرست ماژول‌های سراسری سرور برای بارگذاری. این ماژول‌ها قرار است ویژگی‌هایی را ارائه دهند که لزوماً به یک پایگاه داده خاص گره نخورده‌اند. این برخلاف ماژول‌هایی است که همیشه هنگام نصب به یک پایگاه دادهٔ مشخص متصل می‌شوند (یعنی اکثر افزونه‌های Odoo). پیش‌فرض base,web است.

-c <config>, --config <config>¶: مسیر یک فایل پیکربندی جایگزین. اگر تعریف نشده باشد، Odoo متغیر محیطی ODOO_RC و مکان پیش‌فرض $HOME/.odoorc را بررسی می‌کند. به بخش فایل پیکربندی در پایین مراجعه کنید.

-D <data-dir-path>, --data-dir <data-dir-path>¶: مسیر دایرکتوری برای ذخیرهٔ داده‌های Odoo (مثلاً filestore، نشست‌ها). اگر مشخص نشود، Odoo به مسیر از پیش تعریف‌شده‌ای بازمی‌گردد. در سیستم‌های Unix همان مسیر تعریف‌شده در متغیر محیطی $XDG_DATA_HOME یا ~/.local/share/Odoo یا /var/lib/Odoo است.

-s, --save¶: پیکربندی سرور را در فایل پیکربندی فعلی ذخیره می‌کند (به‌صورت پیش‌فرض $HOME/.odoorc، و می‌توان آن را با -c بازنویسی کرد).

--with-demo¶: داده‌های نمایشی را در پایگاه‌های دادهٔ جدید نصب می‌کند.

--without-demo¶: داده‌های نمایشی را نه در پایگاه‌های دادهٔ جدید و نه هنگام نصب ماژول‌های جدید در پایگاه‌های دادهٔ دارای داده‌های نمایشی نصب نکن؛ این حالت پیش‌فرض است.

--skip-auto-install¶: هنگام درخواست نصب یک ماژول جدید، از نصب خودکار ماژول‌ها صرف‌نظر می‌کند. این گزینه برای توسعه مفید است. برای بررسی این کار به کار می‌رود که آیا ماژول‌های نصب‌شده به‌طور غیرمستقیم به ماژول‌های با نصب خودکار وابسته نیستند.

--pidfile=<pidfile>¶: مسیر فایلی که pid سرور در آن ذخیره خواهد شد

--stop-after-init¶: سرور را پس از مقداردهی اولیه‌اش متوقف می‌کند.

--geoip-city-db <path>¶: مسیر مطلق به فایل پایگاه دادهٔ GeoIP City.

--geoip-country-db <path>¶: مسیر مطلق به فایل پایگاه دادهٔ GeoIP Country.

آزمایش¶

--test-enable¶: آزمون‌ها را پس از نصب ماژول اجرا می‌کند

--test-file <file>¶: یک فایل آزمون Python را اجرا می‌کند

--test-tags [-][tag][/module][:class][.method]¶

فهرست جداشده با کاما از مشخصات برای فیلتر کردن آزمون‌هایی که باید اجرا شوند. اگر تنظیم شود، آزمون‌های واحد را فعال می‌کند.

مثال: --test-tags :TestClass.test_func,/test_module,external

علامت - مشخص می‌کند که می‌خواهیم آزمون‌های منطبق با این مشخصات را شامل کنیم یا حذف کنیم.
این برچسب با برچسب‌های افزوده‌شده روی یک کلاس از طریق دکوریتر tagged() مطابقت می‌کند (همهٔ کلاس‌های آزمون تا زمانی که صراحتاً حذف نشده باشند، دارای برچسب‌های standard و at_install هستند؛ مستندات دکوریتر را ببینید).
* با همهٔ برچسب‌ها مطابقت می‌کند.
اگر در حالت شامل‌سازی، برچسب حذف شود، مقدار آن standard خواهد بود.
اگر در حالت حذف، برچسب حذف شود، مقدار آن * خواهد بود.
ماژول، کلاس و متد به ترتیب با نام ماژول، نام کلاس آزمون و نام متد آزمون مطابقت می‌کنند.

فیلتر کردن و اجرای آزمون‌ها دو بار اتفاق می‌افتد: درست پس از هر نصب/به‌روزرسانی ماژول و در پایان بارگذاری ماژول‌ها. در هر مرحله، آزمون‌ها بر اساس مشخصات --test-tags و علاوه بر آن به ترتیب با مشخصات پویای at_install و post_install فیلتر می‌شوند.

--screenshots¶: دایرکتوری‌ای را که هنگام شکست یک آزمون HttpCase.browser_js، اسکرین‌شات‌ها باید در آن نوشته شوند مشخص کنید. پیش‌فرض آن /tmp/odoo_tests/db_name/screenshots است

--screencasts¶: ضبط ویدیویی صفحه را فعال کنید و دایرکتوری ذخیرهٔ فایل‌های ضبط‌شده را مشخص کنید. ابزار ffmpeg باید نصب شود تا فریم‌ها را در یک فایل ویدیویی کدگذاری کند. در غیر این صورت، به جای فایل ویدیویی، فریم‌ها نگه داشته می‌شوند.

پایگاه داده¶

-r <user>, --db_user <user>¶: نام کاربری پایگاه داده، که برای اتصال به PostgreSQL استفاده می‌شود.

-w <password>, --db_password <password>¶: رمز عبور پایگاه داده، در صورت استفاده از password authentication.

--db_host <hostname>¶

میزبان برای سرور پایگاه داده

localhost در Windows
در غیر این صورت سوکت UNIX

--db_port <port>¶: پورتی که پایگاه داده روی آن گوش می‌دهد، پیش‌فرض ۵۴۳۲

--db_replica_host <hostname>¶: میزبان برای سرور پایگاه دادهٔ تکراری، در صورت تنظیم نشدن / خالی بودن غیرفعال است

--db_replica_port <port>¶: پورتی که پایگاه دادهٔ تکراری روی آن گوش می‌دهد، پیش‌فرض --db_port

--db-filter <filter>¶

پایگاه‌های داده‌ای که با <filter> مطابقت ندارند را برای رابط کاربری وب پنهان می‌کند. این فیلتر یک regular expression است، با این موارد اضافه:

%h با کل نام میزبانی که درخواست روی آن انجام شده، جایگزین می‌شود.
%d با زیردامنه‌ای که درخواست روی آن انجام شده، جایگزین می‌شود، به استثنای www (بنابراین دامنهٔ odoo.com و www.odoo.com هر دو با پایگاه دادهٔ odoo مطابقت می‌کنند).

این عملیات به حروف کوچک و بزرگ حساس هستند. گزینهٔ (?i) را اضافه کنید تا با همهٔ پایگاه‌های داده مطابقت کند (بنابراین دامنهٔ odoo.com با استفاده از (?i)%d با پایگاه دادهٔ Odoo مطابقت می‌کند).

از نسخهٔ ۱۱ به بعد، همچنین می‌توان با استفاده از پارامتر --database و مشخص کردن فهرستی جداشده با کاما از پایگاه‌های داده، دسترسی به گوش دادن به یک پایگاه دادهٔ مشخص را محدود کرد

هنگام ترکیب این دو پارامتر، db-filter برای محدود کردن فهرست پایگاه‌های داده بر فهرست جداشده با کاما اولویت دارد، در حالی که فهرست جداشده با کاما برای انجام عملیات درخواست‌شده مانند ارتقای ماژول‌ها استفاده می‌شود.

$ odoo-bin --db-filter ^11.*$

دسترسی به پایگاه‌های داده‌ای که نامشان با 11 شروع می‌شود را محدود کنید

$ odoo-bin --database 11firstdatabase,11seconddatabase

دسترسی را فقط به دو پایگاه داده، 11firstdatabase و 11seconddatabase محدود کنید

$ odoo-bin --database 11firstdatabase,11seconddatabase -u base

دسترسی را فقط به دو پایگاه داده، 11firstdatabase و 11seconddatabase محدود کنید، و ماژول base را روی یک پایگاه داده به‌روزرسانی کنید: 11firstdatabase. اگر پایگاه دادهٔ 11seconddatabase وجود نداشته باشد، پایگاه داده ایجاد می‌شود و ماژول‌های base نصب می‌شوند

$ odoo-bin --db-filter ^11.*$ --database 11firstdatabase,11seconddatabase -u base

دسترسی به پایگاه‌های داده‌ای که نامشان با 11 شروع می‌شود را محدود کنید، و ماژول base را روی یک پایگاه داده به‌روزرسانی کنید: 11firstdatabase. اگر پایگاه دادهٔ 11seconddatabase وجود نداشته باشد، پایگاه داده ایجاد می‌شود و ماژول‌های base نصب می‌شوند

هشدار

این گزینه روی کارگران cron تأثیر نمی‌گذارد؛ اگر --database داده نشود، کارگران cron روی هر پایگاه دادهٔ در دسترس اجرا خواهند شد

--db-template <template>¶: هنگام ایجاد پایگاه‌های دادهٔ جدید از صفحات مدیریت پایگاه داده، از template database مشخص‌شده استفاده کنید. پیش‌فرض template0 است.

--pg_path </path/to/postgresql/binaries>¶: مسیر فایل‌های اجرایی PostgreSQL که توسط مدیر پایگاه داده برای dump و بازیابی پایگاه‌های داده استفاده می‌شوند. تنها در صورتی باید این گزینه را مشخص کنید که این فایل‌های اجرایی در یک دایرکتوری غیراستاندارد قرار داشته باشند.

--no-database-list¶: قابلیت فهرست‌بندی پایگاه‌های دادهٔ موجود در سیستم را غیرفعال می‌کند

--db_sslmode¶: امنیت SSL اتصال بین Odoo و PostgreSQL را کنترل می‌کند. مقدار باید یکی از 'disable'، 'allow'، 'prefer'، 'require'، 'verify-ca' یا 'verify-full' باشد. مقدار پیش‌فرض 'prefer' است

--unaccent¶: هنگام ایجاد پایگاه‌های دادهٔ جدید، فعال‌سازی افزونهٔ unaccent را امتحان کنید

ایمیل‌ها¶

--email-from <address>¶: آدرس ایمیلی که هنگامی که Odoo نیاز به ارسال ایمیل دارد، به‌عنوان <FROM> استفاده می‌شود

--from-filter <address or domain>¶: تعیین می‌کند که پیکربندی SMTP بر کدام آدرس ایمیل اعمال شود. این فیلد می‌تواند نام دامنه یا یک آدرس ایمیل کامل باشد، یا می‌تواند خالی بماند. اگر آدرس ایمیل فرستنده با این فیلتر تنظیم‌شده مطابقت نداشته باشد، ایمیل با استفاده از ترکیبی از دو پارامتر سیستم: mail.default.from و mail.catchall.domain کپسوله می‌شود. برای مثال، "Admin" <admin@example.com> => "Admin" <notifications@mycompany.com>.

--smtp <server>¶: آدرس سرور SMTP برای اتصال جهت ارسال ایمیل

--smtp-port <port>¶

--smtp-ssl¶: اگر تنظیم شود، odoo باید از اتصالات SMTP با SSL/STARTSSL استفاده کند

--smtp-user <name>¶: نام کاربری برای اتصال به سرور SMTP

--smtp-password <password>¶: رمز عبور برای اتصال به سرور SMTP

--smtp-ssl-certificate-filename <path/to/cert.pem>¶: از یک گواهی SSL برای احراز هویت استفاده می‌شود. اگر تنظیم شود، آنگاه smtp-ssl-private-key الزامی است.

--smtp-ssl-private-key-filename <path/to/key.pem>¶: از یک کلید خصوصی SSL برای احراز هویت استفاده می‌شود. اگر تنظیم شود، آنگاه smtp-ssl-certificate الزامی است.

بین‌المللی‌سازی¶

--load-language <languages>¶: زبان‌ها (جداشده با کاما) را برای ترجمه‌هایی که می‌خواهید بارگذاری شوند، مشخص می‌کند

--i18n-overwrite¶: اصطلاحات ترجمهٔ موجود را هنگام به‌روزرسانی یک ماژول یا وارد کردن یک فایل CSV یا PO بازنویسی می‌کند.

گزینه‌های پیشرفته¶

ویژگی‌های توسعه‌دهنده¶

--dev <feature,feature,...,feature>¶

فهرست جداشده با کاما از ویژگی‌ها. فقط برای اهداف توسعه. در محیط تولید از آن استفاده نکنید. ویژگی‌های ممکن عبارت‌اند از:

all: نام مستعار برای xml,reload,qweb,access
xml: قالب QWeb را به‌جای پایگاه داده، مستقیماً از فایل xml بخوان. هنگامی که یک قالب در پایگاه داده تغییر کرده باشد، تا به‌روزرسانی/مقداردهی بعدی از فایل xml خوانده نمی‌شود. به‌ویژه، قالب‌ها هنگام استفاده از این گزینه ترجمه نمی‌شوند.
reload: هنگام به‌روزرسانی فایل python، سرور را راه‌اندازی مجدد می‌کند (ممکن است بسته به ویرایشگر متنی مورد استفاده، تشخیص داده نشود)
qweb: در ارزیابی قالب QWeb هنگامی که یک گره حاوی t-debug='debugger' باشد، توقف می‌کند
werkzeug: در صورت بروز استثنا، traceback کامل را در صفحهٔ فرانت‌اند نمایش می‌دهد
replica: --db_replica_host را شبیه‌سازی می‌کند اما به همان سرور پایگاه داده مانند --db_host متصل می‌شود؛ این کار آزمایش ویژگی‌های فقط‌خواندنی را بدون نیاز به راه‌اندازی یک پایگاه دادهٔ تکراری ممکن می‌سازد.
access: traceback را در کنار AccessError هنگامی که منجر به پاسخ HTTP 403 - Forbidden می‌شود، ثبت می‌کند.

HTTP¶

--no-http¶: کارگران HTTP یا long-polling را راه‌اندازی نکن (ممکن است همچنان کارگران cron را راه‌اندازی کند)

هشدار
اگر --test-enable تنظیم شده باشد، تأثیری ندارد، زیرا آزمون‌ها به یک سرور HTTP در دسترس نیاز دارند

--http-interface <interface>¶: آدرس TCP/IP که سرور HTTP روی آن گوش می‌دهد، پیش‌فرض 0.0.0.0 (همهٔ آدرس‌ها)

-p <port>¶

--http-port <port>¶: پورتی که سرور HTTP روی آن گوش می‌دهد، پیش‌فرض ۸۰۶۹.

--gevent-port <port>¶: پورت TCP برای اتصالات websocket در حالت چندپردازشی یا gevent، پیش‌فرض ۸۰۷۲. در حالت پیش‌فرض (نخی) استفاده نمی‌شود.

--proxy-mode¶

استفاده از سرآیندهای X-Forwarded-* را از طریق Werkzeug's proxy support فعال می‌کند.

اگر X-Forwarded-Host در درخواست وجود نداشته باشد، همهٔ سرآیندهای X-Forwarded-* را نادیده می‌گیرد.

همیشه IP واقعی را از آخرین ورودی زنجیرهٔ X-Forwarded-For می‌گیرد. سرور وب خود را با استفاده از دستوراتی مانند set_real_ip_from در nginx به‌درستی پیکربندی کنید، در صورتی که پراکسی‌های قابل اعتماد دیگری در طول زنجیره وجود داشته باشند که باید نادیده گرفته شوند.

X-Forwarded-Proto و X-Forwarded-Host برای به‌روزرسانی URL ریشهٔ درخواست استفاده می‌شوند، که به نوبهٔ خود برای به‌روزرسانی پارامتر سیستم web.base.url پس از یک احراز هویت موفق مدیر استفاده می‌شود. این پارامتر سیستم برای تولید همهٔ پیوندهای پایگاه دادهٔ فعلی استفاده می‌شود؛ به Web base URL یک پایگاه داده مراجعه کنید.

هشدار

حالت پراکسی نباید خارج از یک سناریوی پراکسی معکوس فعال شود

--x-sendfile¶: ارائهٔ فایل‌های پیوست را به سرور وب استاتیک واگذار می‌کند و هر دو سرآیند http X-Sendfile (apache) و X-Accel-* (nginx) را روی پاسخ‌های جریانی تنظیم می‌کند. برای پیکربندی سرور وب به ارائهٔ فایل‌های static و پیوست‌ها مراجعه کنید.

لاگ‌گیری¶

به‌صورت پیش‌فرض، Odoo همهٔ لاگ‌های level INFO، WARNING و ERROR را نمایش می‌دهد. همهٔ لاگ‌ها مستقل از سطح، روی stderr خروجی می‌گیرند. گزینه‌های مختلفی برای هدایت لاگ به مقاصد دیگر و سفارشی‌سازی میزان جزئیات در دسترس است.

--logfile <file>¶: خروجی لاگ را به‌جای stderr به فایل مشخص‌شده می‌فرستد. در Unix، این فایل می‌تواند توسط برنامه‌های چرخش لاگ خارجی مدیریت شود و هنگام جایگزینی به‌طور خودکار دوباره باز می‌شود

--syslog¶

به لاگر رویداد سیستم می‌نویسد: syslog on unices و the Event Log on Windows.

هیچ‌کدام قابل پیکربندی نیستند

--log-db <dbname>¶: به مدل ir.logging (جدول ir_logging) پایگاه دادهٔ مشخص‌شده لاگ می‌نویسد. پایگاه داده می‌تواند نام یک پایگاه داده در PostgreSQL «فعلی» باشد، یا a PostgreSQL URI برای مثال برای تجمیع لاگ.

--log-handler <handler-spec>¶

LOGGER:LEVEL، LOGGER را در LEVEL ارائه‌شده فعال می‌کند، مثلاً odoo.models:DEBUG همهٔ پیام‌های لاگ در سطح DEBUG یا بالاتر را در مدل‌ها فعال می‌کند.

دونقطهٔ : اجباری است
لاگر را می‌توان حذف کرد تا گردانندهٔ ریشه (پیش‌فرض) پیکربندی شود
اگر سطح حذف شود، لاگر روی INFO تنظیم می‌شود

این گزینه را می‌توان برای پیکربندی چندین لاگر تکرار کرد، مثلاً

$ odoo-bin --log-handler :DEBUG --log-handler werkzeug:CRITICAL --log-handler odoo.fields:WARNING

--log-web¶: لاگ‌گیری DEBUG درخواست‌ها و پاسخ‌های HTTP را فعال می‌کند، معادل --log-handler=odoo.http:DEBUG

--log-sql¶: لاگ‌گیری DEBUG پرس‌وجوی SQL را فعال می‌کند، معادل --log-handler=odoo.sql_db:DEBUG

--log-level <level>¶

میان‌بری برای تنظیم آسان‌تر سطوح از پیش تعریف‌شده روی لاگرهای خاص. سطوح «واقعی» (critical، error، warn، debug) روی لاگرهای odoo و werkzeug تنظیم می‌شوند (به استثنای debug که فقط روی odoo تنظیم می‌شود).

Odoo همچنین سطوح کاذب اشکال‌زدایی ارائه می‌دهد که برای مجموعه‌های مختلف لاگرها اعمال می‌شوند:

debug_sql

لاگر SQL را روی debug تنظیم می‌کند

معادل --log-sql

debug_rpc

لاگرهای odoo و درخواست HTTP را روی debug تنظیم می‌کند

equivalent to --log-level debug --log-request

debug_rpc_answer

لاگرهای odoo و درخواست و پاسخ HTTP را روی debug تنظیم می‌کند

معادل --log-level debug --log-request --log-response

توجه

در صورت تعارض بین --log-level و --log-handler، از دومی استفاده می‌شود

چندپردازشی¶

--workers <count>¶

اگر count صفر نباشد (پیش‌فرض)، چندپردازشی را فعال می‌کند و تعداد مشخص‌شده‌ای از کارگران HTTP (زیرپردازش‌هایی که درخواست‌های HTTP و RPC را پردازش می‌کنند) را راه‌اندازی می‌کند.

توجه

حالت چندپردازشی فقط در سیستم‌های مبتنی بر Unix در دسترس است

تعدادی از گزینه‌ها محدود کردن و بازیافت کارگران را امکان‌پذیر می‌کنند:

--limit-request <limit>¶

تعداد درخواست‌هایی که یک کارگر قبل از بازیافت و راه‌اندازی مجدد پردازش می‌کند.

پیش‌فرض ۸۱۹۶.

--limit-memory-soft <limit>¶

حداکثر حافظهٔ مجازی مجاز برای هر کارگر بر حسب بایت. اگر از این حد فراتر رود، کارگر در پایان درخواست فعلی کشته و بازیافت می‌شود.

پیش‌فرض 2048MiB (2048*1024*1024B).

--limit-memory-hard <limit>¶

محدودیت سخت روی حافظهٔ مجازی بر حسب بایت؛ هر کارگری که از این حد فراتر رود، بلافاصله بدون انتظار برای پایان پردازش درخواست فعلی کشته می‌شود.

پیش‌فرض 2560MiB (2560*1024*1024B).

--limit-time-cpu <limit>¶

از استفادهٔ کارگر از بیش از <limit> ثانیهٔ CPU برای هر درخواست جلوگیری می‌کند. اگر از این حد فراتر رود، کارگر کشته می‌شود.

پیش‌فرض ۶۰.

--limit-time-real <limit>¶

از این جلوگیری می‌کند که کارگر بیش از <limit> ثانیه برای پردازش یک درخواست زمان ببرد. اگر از این حد فراتر رود، کارگر کشته می‌شود.

با --limit-time-cpu در این تفاوت دارد که این یک محدودیت «زمان کلی» شامل مثلاً پرس‌وجوهای SQL است.

پیش‌فرض ۱۲۰.

--max-cron-threads <count>¶

تعداد کارگران اختصاص‌داده‌شده به کارهای cron. پیش‌فرض ۲. کارگران در حالت چندنخی، نخ هستند و در حالت چندپردازشی، پردازش هستند.

برای حالت چندپردازشی، این علاوه بر پردازش‌های کارگر HTTP است.

--limit-time-worker-cron <limit>¶

محدودیت نرم روی اینکه یک نخ/کارگر cron پیش از راه‌اندازی مجدد چقدر اجازهٔ زنده ماندن دارد، بر حسب ثانیه.

برای غیرفعال‌سازی روی ۰ تنظیم کنید.

پیش‌فرض ۰.

فایل پیکربندی¶

بیشتر گزینه‌های خط فرمان را می‌توان از طریق یک فایل پیکربندی نیز مشخص کرد. بیشتر اوقات، از نام‌های مشابه با حذف پیشوند - و جایگزینی - دیگر با _ استفاده می‌کنند، مثلاً --db-template تبدیل می‌شود به db_template.

برخی تبدیل‌ها با این الگو مطابقت ندارند:

--db-filter تبدیل می‌شود به dbfilter
--no-http معادل بولین http_enable است
تنظیمات از پیش تعیین‌شدهٔ لاگ‌گیری (همهٔ گزینه‌های شروع‌شده با --log- به جز --log-handler و --log-db) فقط محتوا را به log_handler اضافه می‌کنند؛ مستقیماً از آن در فایل پیکربندی استفاده کنید
--smtp به‌صورت smtp_server ذخیره می‌شود
--database به‌صورت db_name ذخیره می‌شود

فایل پیکربندی پیش‌فرض $HOME/.odoorc است که می‌توان آن را با --config بازنویسی کرد. مشخص کردن --save وضعیت پیکربندی فعلی را در آن فایل ذخیره می‌کند. آیتم‌های پیکربندی مرتبط با خط فرمان باید در بخش [options] مشخص شوند.

اینجا یک نمونه فایل است:

[options]
db_user=odoo
dbfilter=odoo

`shell` - باز کردن یک Shell¶

خط فرمان Odoo همچنین اجازه می‌دهد Odoo را به‌عنوان یک محیط کنسول Python راه‌اندازی کنید و امکان تعامل مستقیم با orm و قابلیت‌های آن را فراهم می‌کند. از آنجا که اجرای یک shell شامل راه‌اندازی سرور است، گزینه‌های فایل پیکربندی اعمال می‌شوند.

$ odoo-bin shell

Example

افزودن یک علامت تعجب به نام همهٔ مخاطبین:

In [1]: records = env["res.partner"].search([])

In [2]: records
Out[2]: res.partner(14, 26, 33, 21, 10)

In [3]: for partner in records:
   ...:     partner.name = "%s !" % partner.name
   ...:

In [4]: env.cr.commit()

مهم

به‌صورت پیش‌فرض، shell در حالت تراکنشی اجرا می‌شود. این بدان معناست که هر تغییری که در پایگاه داده ایجاد شود، هنگام خروج از shell بازگردانده می‌شود. برای ثبت تغییرات، از env.cr.commit() استفاده کنید.

--shell-file <init_script.py>¶: یک اسکریپت Python برای اجرا پس از شروع shell مشخص کنید. متغیر محیطی PYTHONSTARTUP را بازنویسی می‌کند.

--shell-interface (ipython|ptpython|bpython|python)¶: یک REPL ترجیحی برای استفاده در حالت shell مشخص کنید. این shell با متغیر env که از قبل مقداردهی شده، راه‌اندازی می‌شود تا بتواند به ORM و دیگر ماژول‌های Odoo دسترسی داشته باشد.

همچنین ببینید

محیط

`db` - مدیریت یک پایگاه داده¶

این فرمان به شما اجازه می‌دهد پایگاه‌های داده را از طریق رابط خط فرمان مدیریت کنید. عملیات با استفاده از زیرفرمان‌ها مشخص می‌شوند.

برای همهٔ زیرفرمان‌ها، این گزینه‌ها برای پیکربندی محیط شما در دسترس‌اند:

--addons-path
--config
--data-dir
--db_user
--db_password
--db_host
--db_port
--db_sslmode
--pg_path

`db init` - مقداردهی اولیهٔ یک پایگاه داده¶

این فرمان یک پایگاه دادهٔ جدید ایجاد می‌کند و ماژول base را نصب می‌کند. می‌توانید زبان و کشور شرکت اصلی را مشخص کنید.

$ odoo-bin db init <database>

database¶: نام پایگاه داده‌ای که باید مقداردهی اولیه شود.

--with-demo¶: داده‌های نمایشی را در پایگاه دادهٔ مقداردهی‌شده نصب کنید.

--force¶: اگر پایگاه داده از قبل وجود داشته باشد، پیش از مقداردهی اولیهٔ پایگاه دادهٔ جدید، آن را حذف کنید.

--country <country_iso_code>¶: کد کشوری که باید روی شرکت اصلی تنظیم شود

--language <language_code>¶: زبان پیش‌فرض برای نمونه، پیش‌فرض en_US

--username <password>¶: نام کاربری برای پایگاه دادهٔ جدید، پیش‌فرض admin

--password <password>¶: رمز عبور برای پایگاه دادهٔ جدید، پیش‌فرض admin

`db dump` - ذخیرهٔ یک Dump پایگاه داده¶

یک فایل dump ایجاد می‌کند.

$ odoo-bin db dump <database> <dump_path>

database¶: نام پایگاه داده‌ای که باید از آن dump گرفته شود.

dump_path¶: (اختیاری) پایگاه داده در مسیر مشخص‌شده dump می‌شود. به‌صورت پیش‌فرض، در stdout dump می‌شود.

--format <zip | dump>¶: در صورت ارائه، پایگاه داده با استفاده از قالب مشخص‌شده dump می‌شود. قالب‌های پشتیبانی‌شده zip (پیش‌فرض) و dump (قالب pg_dump) هستند.

--no-filestore¶: در صورت ارائه، پایگاه دادهٔ zip بدون filestore دامپ می‌شود

`db load` - بارگذاری یک Dump پایگاه داده¶

یک فایل dump را در یک پایگاه دادهٔ Odoo بارگذاری می‌کند؛ فایل dump می‌تواند یک URL باشد.

$ odoo-bin db load <database> <dump_file>

database¶: (اختیاری) نام پایگاه داده‌ای که باید از dump ایجاد شود. در صورت عدم ارائه، از نام فایل dump بدون پسوند استفاده می‌شود.

dump_file¶: فایل .zip یا pg_dump که باید بارگذاری شود.

-f,--force¶: اگر پایگاه داده از قبل وجود داشته باشد، پیش از بارگذاری پایگاه دادهٔ جدید، آن را حذف کنید.

-n,--neutralize¶: پایگاه داده را پس از بازیابی، خنثی کنید.

`db duplicate` - تکثیر یک پایگاه داده¶

یک پایگاه داده را شامل filestore تکثیر کنید.

$ odoo-bin db duplicate <source> <target>

source¶: نام پایگاه دادهٔ منبع.

target¶: نام پایگاه دادهٔ هدف.

-n,--neutralize¶: پایگاه داده را پس از بازیابی، خنثی کنید.

-f,--force¶: اگر پایگاه دادهٔ هدف از قبل وجود داشته باشد، پیش از مقداردهی اولیهٔ پایگاه دادهٔ جدید، آن را حذف کنید.

`db rename` - تغییر نام یک پایگاه داده¶

نام یک پایگاه داده را از نام قدیمی به نامی جدید تغییر دهید.

$ odoo-bin db rename <source> <target>

source¶: نام فعلی پایگاه داده.

target¶: نام جدید برای پایگاه داده.

-f,--force¶: اگر پایگاه دادهٔ هدف از قبل وجود داشته باشد، پیش از تغییر نام پایگاه دادهٔ منبع، آن را حذف کنید.

`db drop` - حذف یک پایگاه داده¶

$ odoo-bin db drop <database>

database¶: نام پایگاه داده‌ای که باید حذف شود.

`i18n` - بین‌المللی‌سازی¶

این فرمان دارای زیرفرمان‌هایی است که به شما اجازه می‌دهد فایل‌های بین‌المللی‌سازی را وارد یا خروجی بگیرید و زبان‌ها را در نمونهٔ Odoo راه‌اندازی کنید.

برای همهٔ زیرفرمان‌ها، این گزینه‌ها برای پیکربندی محیط شما در دسترس‌اند:

--addons-path
--config
--database

توجه

کدهای زبان باید از قالب locale XPG (POSIX) پیروی کنند.

برای فهرست کردن کدهای موجود، می‌توانید با پرس‌وجوی پایگاه داده آن‌ها را جستجو کنید:

$ psql -d <dbname> -c "SELECT iso_code FROM res_lang ORDER BY iso_code"

همچنین ببینید

GNU libc Locale Names

Example

$ odoo-bin i18n loadlang -l en         # English (U.S.)
$ odoo-bin i18n loadlang -l es es_AR   # Spanish (Spain, Argentina)
$ odoo-bin i18n loadlang -l sr@latin   # Serbian (Latin)

`i18n import` - وارد کردن فایل‌های i18n¶

این فرمان فایل‌های ترجمهٔ ارائه‌شده را در قالب‌های .po یا .csv وارد می‌کند. به‌صورت پیش‌فرض، فقط ورودی‌های جدید اضافه می‌شوند، اما می‌توانید انتخاب کنید که اصطلاحات موجود را بازنویسی کنید. همهٔ فایل‌ها باید به زبان مشخص‌شده ارجاع دهند.

$ odoo-bin i18n import <files> --overwrite --language <language_code>

files¶: فهرست فایل‌هایی که باید وارد شوند.

پسوندهای مجاز: .po، .csv.

-l,--language¶: (الزامی) کد زبان ترجمه‌های موجود در فایل‌ها.

-w,--overwrite¶: هنگام وارد کردن، ترجمهٔ موجود را بازنویسی کنید.

`i18n export` - خروجی گرفتن از فایل‌های i18n¶

این فرمان اصطلاحات ترجمهٔ موجود برای ماژول‌های موجود در پایگاه دادهٔ Odoo را به طیفی از قالب‌ها خروجی می‌گیرد: .po، .pot، .tgz، .csv. در مورد فایل‌های .po و .pot، آن‌ها در پوشهٔ i18n/ ماژولی که به آن تعلق دارند ایجاد می‌شوند. اگر پارامتر خروجی را مشخص کنید، فقط یک زبان می‌تواند انتخاب شود، و همهٔ خروجی به آن زبان ارجاع خواهد داشت. قالب خروجی .tgz همهٔ خروجی را در یک فایل واحد بایگانی می‌کند.

$ odoo-bin i18n export <modules> --languages <language_codes>

modules¶: فهرست ماژول‌هایی که می‌خواهید فایل‌های بین‌المللی‌سازی را از آن‌ها خروجی بگیرید.

-l,--languages <languages>¶: فهرست کدهای زبانی که می‌خواهید خروجی بگیرید، pot برای قالب (پیش‌فرض).

-o,--output¶: مسیر یک فایل خروجی واحد با ترجمه‌های همهٔ ماژول‌های ارائه‌شده.

پسوندهای مجاز: .po، .pot، .tgz، .csv

اگر - ارائه شود، محتوا به‌عنوان یک فایل .po در stdout نوشته می‌شود.

هنگامی که این گزینه فعال است، فقط یک زبان مجاز است.

`i18n loadlang` - بارگذاری زبان¶

این فرمان یکی از زبان‌های در دسترس را در پایگاه دادهٔ Odoo بارگذاری و آن را فعال می‌کند.

$ odoo-bin i18n loadlang <languages>

languages¶: کدهای زبانی زبان‌هایی که باید نصب شوند.

`module` - مدیریت ماژول‌ها¶

این فرمان دارای زیرفرمان‌هایی است که به شما اجازه می‌دهد ماژول‌ها را روی نمونهٔ Odoo نصب، حذف نصب و ارتقا دهید. همچنین فرمانی برای نصب اجباری داده‌های نمایشی در پایگاه داده وجود دارد.

برای همهٔ زیرفرمان‌ها، این گزینه‌ها در دسترس‌اند:

--addons-path
--config
--database

`module install` - نصب ماژول‌ها¶

این فرمان همهٔ ماژول‌های انتخاب‌شده را بلافاصله نصب می‌کند.

پیش از نصب ماژول‌ها، پایگاه دادهٔ Odoo باید روی نمونهٔ PostgreSQL شما ایجاد و مقداردهی اولیه شده باشد، مثلاً با استفاده از فرمان db init - مقداردهی اولیهٔ یک پایگاه داده.

$ odoo-bin module install <modules>

modules¶: فهرست ماژول‌هایی که می‌خواهید نصب کنید.

`module uninstall` - حذف نصب ماژول‌ها¶

این فرمان همهٔ ماژول‌های انتخاب‌شده را بلافاصله حذف نصب می‌کند.

$ odoo-bin module uninstall <modules>

modules¶: فهرست ماژول‌هایی که می‌خواهید حذف نصب کنید.

`module upgrade` - ارتقای ماژول‌ها¶

این فرمان همهٔ ماژول‌های انتخاب‌شده را بلافاصله ارتقا می‌دهد.

$ odoo-bin module upgrade <modules>

modules¶: فهرست ماژول‌هایی که می‌خواهید ارتقا دهید. از base یا all برای همهٔ ماژول‌های نصب‌شده استفاده کنید.

--outdated¶: فقط ماژول‌هایی را به‌روزرسانی کن که نسخهٔ جدیدتری روی دیسک دارند. اگر all به‌عنوان آرگومان modules استفاده شود، این به همهٔ ماژول‌های نصب‌شده اعمال می‌شود.

`module forcedemo` - نصب اجباری داده‌های نمایشی¶

این فرمان نصب دادهٔ نمایشی را اجباری می‌کند

هشدار

پس از نصب، هیچ راهی برای واگرد کردن آن وجود ندارد، بنابراین ممکن است بخواهید ابتدا یک پشتیبان از پایگاه داده با فرمان db dump ذخیره کنید

هیچ گزینهٔ اضافه‌ای برای این فرمان وجود ندارد.

`neutralize` - خنثی کردن یک پایگاه داده¶

خط فرمان Odoo همچنین اجازهٔ خنثی کردن یک پایگاه داده را می‌دهد. فرمان باید با یک گزینهٔ پایگاه داده اجرا شود.

$ odoo-bin --addons-path <PATH,...> neutralize -d <database>

-d <database>, --database <database>¶: نام پایگاه داده‌ای را که می‌خواهید خنثی کنید، مشخص کنید.

--stdout¶: به جای اعمال SQL خنثی‌سازی، آن را خروجی بگیرید

همچنین ببینید

پایگاه داده خنثی‌شده

`scaffold` - ساخت اسکلت یک ماژول¶

Scaffolding ایجاد خودکار یک ساختار اسکلت برای ساده‌سازی راه‌اندازی اولیه (در مورد Odoo، ماژول‌های جدید) است. اگرچه ضروری نیست، اما از زحمت راه‌اندازی ساختارهای پایه و جستجوی پیش‌نیازهای شروع جلوگیری می‌کند.

Scaffolding از طریق زیرفرمان odoo-bin scaffold در دسترس است.

$ odoo-bin scaffold my_module /addons/

name (required)¶: نام ماژولی که باید ایجاد شود، که ممکن است به روش‌های مختلف برای تولید نام‌های برنامه‌نویسی (مثلاً نام دایرکتوری ماژول، نام مدل‌ها، …) دستکاری شود

destination (default=current directory)¶: دایرکتوری‌ای که ماژول جدید در آن ایجاد می‌شود، پیش‌فرض دایرکتوری فعلی

-t <template>¶: یک دایرکتوری قالب؛ فایل‌ها از jinja2 عبور داده می‌شوند و سپس به دایرکتوری destination کپی می‌شوند

این، ماژول my_module را در دایرکتوری /addons/ ایجاد می‌کند.

`populate` - پر کردن یک پایگاه داده¶

Odoo Populate اجازه می‌دهد داده‌های موجود در یک پایگاه دادهٔ مشخص را تکثیر کنید. این می‌تواند برای آزمایش و محک‌زنی هنگامی که جداول بزرگ مورد نیاز است استفاده شود. فرآیند تکثیر، تنوعی را برای برخی فیلدها معرفی می‌کند تا محدودیت‌های UNIQUE را در میان موارد دیگر رعایت کند. همچنین روابط x2Many را دنبال می‌کند.

$ odoo-bin populate -d  my_database --models res.partner,account.move --factors 1000

-d <database>¶: نام پایگاه داده‌ای که باید پر شود

--models <models>¶: فهرست مدل‌هایی که باید پر شوند. مدل‌هایی که دو بار ظاهر می‌شوند فقط یک بار پر می‌شوند.

--factors <factors>¶: فهرست ضرایب پر کردن. در صورتی که ضریبی برای یک مدل وجود نداشته باشد، از آخرین ضریب در فهرست استفاده می‌شود.

--sep <separator>¶: جداکنندهٔ مورد استفاده برای تولید نام رکوردها

`cloc` - شمارش خطوط کد¶

Odoo Cloc ابزاری برای شمارش تعداد خطوط مرتبط کد نوشته‌شده در Python، JavaScript، CSS، SCSS یا XML است. این می‌تواند به‌عنوان معیاری تقریبی برای قیمت‌گذاری نگهداری ماژول‌های اضافی استفاده شود.

$ odoo-bin cloc -c config.conf -d my_database

-d <database>, --database <database>¶

کد همهٔ ماژول‌های اضافی نصب‌شده روی پایگاه دادهٔ ارائه‌شده، و همهٔ اقدامات سرور و فیلدهای محاسبه‌شده‌ای را که به‌صورت دستی در پایگاه دادهٔ ارائه‌شده ایجاد شده‌اند، پردازش کنید.
گزینهٔ --addons-path برای مشخص کردن مسیر(های) پوشه(های) ماژول الزامی است.
اگر با --path ترکیب شود، شمارش جمع نتایج هر دو گزینه (با همپوشانی‌های احتمالی) خواهد بود. حداقل یکی از این دو گزینه برای مشخص کردن اینکه کدام کد پردازش شود، الزامی است.

$ odoo-bin cloc --addons-path=addons -d my_database

همچنین ببینید

با گزینهٔ --database

-p <path>, --path <path>¶

فایل‌ها را در مسیر ارائه‌شده پردازش کنید.

اگر با --database ترکیب شود، شمارش جمع نتایج هر دو گزینه (با همپوشانی‌های احتمالی) خواهد بود. حداقل یکی از این دو گزینه برای مشخص کردن اینکه کدام کد پردازش شود، الزامی است.

$ odoo-bin cloc -p addons/account

چندین مسیر را می‌توان با تکرار این گزینه ارائه داد.

$ odoo-bin cloc -p addons/account -p addons/sale

همچنین ببینید

با گزینهٔ --path

--addons-path <directories>¶

فهرستی از دایرکتوری‌ها که با کاما جدا شده‌اند و ماژول‌ها در آن‌ها ذخیره می‌شوند. این دایرکتوری‌ها برای یافتن ماژول‌ها اسکن می‌شوند.

در صورت استفاده از گزینهٔ --database الزامی است.

-c <directories>¶

یک فایل پیکربندی برای استفاده به‌جای گزینهٔ --addons-path مشخص کنید.

-v, --verbose¶

جزئیات خطوط شمرده‌شده برای هر فایل را نشان دهید.

فایل‌های پردازش‌شده¶

با گزینهٔ `--database`¶

Odoo Cloc خطوط هر فایل از ماژول‌های اضافی نصب‌شده در یک پایگاه دادهٔ مشخص را می‌شمارد. علاوه بر این، خطوط Python اقدامات سرور و فیلدهای محاسبه‌شدهٔ سفارشی را که مستقیماً در پایگاه داده ایجاد یا وارد شده‌اند، می‌شمارد. در نهایت، خطوط کد فایل‌های JavaScript، CSS و SCSS و نماهای QWeb را از ماژول‌های واردشده می‌شمارد.

برخی فایل‌ها به‌صورت پیش‌فرض از شمارش حذف می‌شوند:

مانیفست (__manifest__.py یا __openerp__.py)
محتوای پوشهٔ static/lib
آزمون‌های تعریف‌شده در پوشهٔ tests و static/tests
اسکریپت‌های مهاجرت تعریف‌شده در پوشهٔ migrations و upgrades
فایل‌های XML اعلام‌شده در بخش‌های demo یا demo_xml مانیفست

برای موارد خاص، فهرستی از فایل‌هایی که باید توسط Odoo Cloc نادیده گرفته شوند، می‌تواند برای هر ماژول تعریف شود. این با ورودی cloc_exclude مانیفست مشخص می‌شود:

"cloc_exclude": [
    "lib/common.py", # exclude a single file
    "data/*.xml",    # exclude all XML files in a specific folder
    "example/**/*",  # exclude all files in a folder hierarchy recursively
    "**/*.scss",     # exclude all scss file from the module
]

الگوی **/* را می‌توان برای نادیده گرفتن یک ماژول کامل استفاده کرد. این می‌تواند برای حذف یک ماژول از هزینه‌های خدمات نگهداری مفید باشد.

برای اطلاعات بیشتر دربارهٔ نحو الگو، به glob مراجعه کنید.

با گزینهٔ `--path`¶

این روش در صورتی که یک فایل مانیفست در پوشهٔ مشخص‌شده وجود داشته باشد، مانند گزینهٔ --database کار می‌کند. در غیر این صورت، همهٔ فایل‌ها را می‌شمارد.

شناسایی ماژول‌های اضافی¶

برای تمایز بین ماژول‌های استاندارد و اضافی، Odoo Cloc از روش اکتشافی زیر استفاده می‌کند: ماژول‌هایی که (مسیر واقعی سیستم فایل، پس از دنبال کردن پیوندهای نمادین) در همان دایرکتوری والد ماژول‌های استاندارد base، web یا web_enterprise قرار دارند، استاندارد در نظر گرفته می‌شوند. ماژول‌های دیگر به‌عنوان ماژول‌های اضافی تلقی می‌شوند.

مدیریت خطا¶

برخی فایل‌ها را Odoo Cloc نمی‌تواند بشمارد. این فایل‌ها در پایان خروجی گزارش می‌شوند.

حداکثر اندازهٔ فایل تجاوز کرد¶

Odoo Cloc هر فایل بزرگ‌تر از 25MB را رد می‌کند. معمولاً فایل‌های منبع کوچک‌تر از 1 MB هستند. اگر یک فایل رد شود، ممکن است:

یک فایل XML تولیدشده که حاوی داده‌های زیادی است. باید در مانیفست حذف شود.
یک کتابخانهٔ JavaScript که باید در پوشهٔ static/lib قرار بگیرد.

خطای نحو¶

Odoo Cloc نمی‌تواند خطوط کد یک فایل Python با مشکل نحو را بشمارد. اگر یک ماژول اضافی حاوی چنین فایل‌هایی باشد، باید برطرف شوند تا اجازهٔ بارگذاری ماژول داده شود. اگر ماژول علی‌رغم وجود این فایل‌ها کار می‌کند، احتمالاً بارگذاری نمی‌شوند و بنابراین باید از ماژول حذف شوند، یا حداقل در مانیفست از طریق cloc_exclude حذف شوند.

`obfuscate` - مبهم‌سازی پایگاه داده¶

این فرمان روشی سریع و آسان برای مبهم‌سازی برخی از داده‌های نمونهٔ Odoo فراهم می‌کند، که عمدتاً برای اهداف آموزشی یا ساخت ویدیوهای سریع برای تیم پشتیبانی استفاده می‌شود و به تکنسین‌ها کمک می‌کند از نشت اطلاعات حساس جلوگیری کنند.

هشدار

این فرمان باید با احتیاط استفاده شود، زیرا یک روش امن برای ناشناس‌سازی کامل داده‌ها قبل از انتقال به شخص ثالث در نظر گرفته نمی‌شود. تصاویر، پیوست‌های PDF، مبالغ و بسیاری از اطلاعات دیگر ممکن است مبهم‌سازی نشوند و باعث نشت اطلاعات حساس شوند. پیش از به اشتراک‌گذاری داده‌ها، بررسی کاملی لازم است تا اطمینان حاصل شود که هیچ اطلاعات حساسی افشا نمی‌شود.

مبهم‌سازی متقارن است، بنابراین می‌توان محتوا را با استفاده از همان رمز عبور از حالت مبهم خارج کرد.

همهٔ پیکربندی‌های موجود برای فرمان server در اینجا نیز در دسترس هستند.

$ odoo-bin obfuscate --pwd=<password>

--pwd <password>¶: (الزامی) رمز عبوری که برای مبهم‌سازی متقارن محتوا استفاده خواهد شد.

--unobfuscate¶: اگر می‌خواهید به‌جای مبهم‌سازی، از حالت مبهم خارج کنید.

--fields <fields>¶: فهرست جداشده با کاما از ورودی‌های table.column برای مبهم‌سازی/خروج از حالت مبهم.

--file <file>¶: فایل حاوی فهرست ورودی‌های table.column برای مبهم‌سازی/خروج از حالت مبهم.

--exclude¶: فهرست جداشده با کاما از ورودی‌های table.column که نباید مبهم‌سازی/از حالت مبهم خارج شوند.

--allfields¶

فقط هنگامی استفاده می‌شود که --unobfuscate انتخاب شده باشد.

تلاش برای خروج همهٔ فیلدها از حالت مبهم. این از مشخص کردن فیلدها به‌صورت دستی کندتر است.

--vacuum¶

فقط هنگامی استفاده می‌شود که --unobfuscate انتخاب شده باشد.

پس از خروج از حالت مبهم، جداول مبهم‌شده را به‌طور کامل پاک کنید و فضای دیسک استفاده‌نشده را بازپس بگیرید.

--pertablecommit¶

پس از مبهم‌سازی، یک بار برای هر جدول commit کنید.

از تراکنش‌های بزرگی که ممکن است timeout بگیرند یا پس از یک خطا با rollback مواجه شوند، جلوگیری می‌کند.

-y,--yes¶

تأیید دستی نخواه.

فقط در صورتی استفاده کنید که مطمئن باشید با به اشتراک‌گذاری پایگاه داده با شخص ثالث بدون بررسی، اطلاعات حساس را نشت نخواهید داد.

`deploy` - استقرار ماژول از راه دور¶

این فرمان یک ماژول را در یک سرور Odoo از راه دور آپلود کرده و آن را نصب می‌کند. از اتصال دستی به سرور از راه دور ساده‌تر است و نیاز به دسترسی کامل به ماشینی که میزبان نمونهٔ Odoo است ندارد، فقط اعتبارنامه‌های مدیریتی Odoo را می‌خواهد.

$ odoo-bin deploy <path> <url> --db <dbname> --login <login> --password <password>

توجه

پیش‌نیازها:

سرور باید ماژول base_import_module را نصب کرده باشد.
کاربری که با گزینهٔ --login انتخاب شده، باید حقوق مدیریتی داشته باشد.

path¶: مسیر ماژولی که باید مستقر شود

url¶: (اختیاری) url سرور که ماژول باید در آن مستقر شود (پیش‌فرض http://localhost:8069)

db <dbname>¶: نام پایگاه داده (اگر سرور از گزینهٔ --db-filter استفاده نکند)

--login <username>¶: نام کاربری کاربر با حقوق مدیر (پیش‌فرض admin)

--password <password>¶: رمز عبور کاربر با حقوق مدیر (پیش‌فرض admin)

--verify-ssl¶: گواهی SSL سرور را تأیید کنید تا اطمینان حاصل شود که نمونهٔ هدف معتبر است.

--force¶: اگر ماژول از قبل نصب شده است، آن را دوباره مقداردهی اولیه کنید. رکوردهای noupdate="1" را به‌روزرسانی می‌کند.

`upgrade_code` - بازنویسی کد منبع¶

این فرمان کل کد منبع را با استفاده از اسکریپت‌های موجود در پوشهٔ odoo/upgrade_code بازنویسی می‌کند. برای انجام کارهای سنگین هنگام برخورد با مهاجرت‌های بزرگ کد و forward portها استفاده می‌شود.

توجه

همهٔ اسکریپت‌ها تلاش خود را برای مهاجرت کد منبع انجام می‌دهند، اما گلولهٔ نقره‌ای نیستند.

این گزینهٔ --addons-path را می‌پذیرد.

$ odoo-bin upgrade_code --from 18.0 --to 19.0 --dry-run

--script <path>¶: یک اسکریپت تکی را اجرا کنید

--from <version>¶: همهٔ اسکریپت‌ها را با شروع از این نسخه به بعد اجرا کنید

--to <version>¶: برای استفاده با --from. همهٔ اسکریپت‌ها را تا و شامل این نسخه اجرا کنید. پیش‌فرض odoo.release.version است.

--glob <glob>¶: فایل‌هایی که باید بازنویسی شوند را فیلتر کنید، پیش‌فرض هر فایل (**/*) است

--dry-run¶: فایل‌هایی که بازنویسی می‌شدند را فهرست کنید، اما تغییرات را اعمال نکنید

اسکریپت‌های ارتقای کد¶

اسکریپت‌ها باید با نام {version}-{name}.py نام‌گذاری شوند، و باید یک تابع upgrade را نمایش دهند که یک آرگومان file_manager می‌گیرد و خروجی ندارد.

آرگومان file_manager یک دنباله از files است که 3 ویژگی و چند متد کمکی دارند:

path: pathlib.Path که فایل در سیستم فایل قرار دارد.
addon: افزونه‌ای که فایل متعلق به آن است.
content: محتوای قابل بازنویسی فایل (تنبل).
print_progress(current, total): پیشرفت فعلی را خروجی می‌گیرد.

Example

def upgrade(file_manager):
    files = (file for file in file_manager if file.path.suffix == '.py')
    for fileno, file in enumerate(files, start=1):
        file.content = file.content.replace(..., ...)
        file_manager.print_progress(fileno, len(files))

Command-line interface (CLI)¶

نسخه¶

help - Show available commands¶

server - Run the Server¶

آزمایش¶

پایگاه داده¶

ایمیل‌ها¶

بین‌المللی‌سازی¶

گزینه‌های پیشرفته¶

ویژگی‌های توسعه‌دهنده¶

HTTP¶

لاگ‌گیری¶

چندپردازشی¶

فایل پیکربندی¶

shell - باز کردن یک Shell¶

db - مدیریت یک پایگاه داده¶

db init - مقداردهی اولیهٔ یک پایگاه داده¶

db dump - ذخیرهٔ یک Dump پایگاه داده¶

db load - بارگذاری یک Dump پایگاه داده¶

db duplicate - تکثیر یک پایگاه داده¶

db rename - تغییر نام یک پایگاه داده¶

db drop - حذف یک پایگاه داده¶

i18n - بین‌المللی‌سازی¶

i18n import - وارد کردن فایل‌های i18n¶

i18n export - خروجی گرفتن از فایل‌های i18n¶

i18n loadlang - بارگذاری زبان¶

module - مدیریت ماژول‌ها¶

module install - نصب ماژول‌ها¶

module uninstall - حذف نصب ماژول‌ها¶

module upgrade - ارتقای ماژول‌ها¶

module forcedemo - نصب اجباری داده‌های نمایشی¶

neutralize - خنثی کردن یک پایگاه داده¶

scaffold - ساخت اسکلت یک ماژول¶

populate - پر کردن یک پایگاه داده¶

cloc - شمارش خطوط کد¶

فایل‌های پردازش‌شده¶

با گزینهٔ --database¶

با گزینهٔ --path¶

شناسایی ماژول‌های اضافی¶

مدیریت خطا¶

حداکثر اندازهٔ فایل تجاوز کرد¶

خطای نحو¶

obfuscate - مبهم‌سازی پایگاه داده¶

deploy - استقرار ماژول از راه دور¶

upgrade_code - بازنویسی کد منبع¶

اسکریپت‌های ارتقای کد¶

`help` - Show available commands¶

`server` - Run the Server¶

`shell` - باز کردن یک Shell¶

`db` - مدیریت یک پایگاه داده¶

`db init` - مقداردهی اولیهٔ یک پایگاه داده¶

`db dump` - ذخیرهٔ یک Dump پایگاه داده¶

`db load` - بارگذاری یک Dump پایگاه داده¶

`db duplicate` - تکثیر یک پایگاه داده¶

`db rename` - تغییر نام یک پایگاه داده¶

`db drop` - حذف یک پایگاه داده¶

`i18n` - بین‌المللی‌سازی¶

`i18n import` - وارد کردن فایل‌های i18n¶

`i18n export` - خروجی گرفتن از فایل‌های i18n¶

`i18n loadlang` - بارگذاری زبان¶

`module` - مدیریت ماژول‌ها¶

`module install` - نصب ماژول‌ها¶

`module uninstall` - حذف نصب ماژول‌ها¶

`module upgrade` - ارتقای ماژول‌ها¶

`module forcedemo` - نصب اجباری داده‌های نمایشی¶

`neutralize` - خنثی کردن یک پایگاه داده¶

`scaffold` - ساخت اسکلت یک ماژول¶

`populate` - پر کردن یک پایگاه داده¶

`cloc` - شمارش خطوط کد¶

با گزینهٔ `--database`¶

با گزینهٔ `--path`¶

`obfuscate` - مبهم‌سازی پایگاه داده¶

`deploy` - استقرار ماژول از راه دور¶

`upgrade_code` - بازنویسی کد منبع¶