Cloud Storage Solutions v.8

いいえ。この機能はバージョン15以降でのみ利用できます。それ以前のバージョンでは、モジュールは事前定義されたフォルダ構造で動作します:

1. Odoo - 同期の中核フォルダ

2. Models - 各 Odoo ドキュメントタイプ用のフォルダ。例: 'Projects'、'Partners'。domain で区別すると、より具体的なフォルダがある場合があります。例: 'Customer 1 Projects'、'Projects of the Customer 2'、'Internal Projects' など。

3. Objects - 各ドキュメント用フォルダ。例: 'Project 1' または 'Customer 1'

4. この Odoo ドキュメントに関連し、同期されるファイルとフォルダ。

その結果、例えば次のようになります:

• Odoo / Projects / Project 1 /  project 1 に関連するファイルとフォルダ

• Odoo / Customer 1 Projects / Project 1; Odoo / Customer 2 Projects / Project 3, ...

• Odoo / Customers / Customer 1 / customer 1 に関連するファイルとフォルダ

この構造は常にフラットです。つまり階層はそのレベルだけです。そのため、異なるドキュメントタイプを同じ構造内に置けないのは正しいです。フォルダ 'Customer 1' 内に、販売オーダ、請求書、プロジェクトのすべてに関連するファイルを置くことはできません。各ドキュメントタイプには独自のフォルダ（または複数）があります。そうでなければ、依拠する基準がなく、逆方向の同期ができません。

いいえ。本ツールは単一ユーザーのエンドポイントに依存します。同期はすべて 1 人のクラウド管理者（アプリ）で行われます。作成したフォルダ / ファイルのアクセス権は自動化されません。クラウドストレージ側で管理してください。

本アプリは、添付のバイナリ内容が Odoo サーバーではなく Cloud Client に保管されることを前提とします。そのため、Odoo 上の該当添付は URL タイプになり、添付ボックスまたは Cloud Client からいつでもアクセスできます。

セットアップ後は同期が完全に自動のため、手動操作は不要です。同期する Odoo のドキュメントタイプを決め、それぞれに関連モデルを設定してください（顧客、販売オーダまたは購買オーダ、タスク、プロジェクトなど）。

はい。それぞれにルールを用意し、その後フィルタを適用します。例: プロジェクトの種類。

文書を確実に割り当てられるよう、フィルタは互いに排他的にしてください。例: 「顧客だが仕入先ではない」「仕入先だが顧客ではない」。そうしないと、特定文書のフォルダがモデル間を行き来します。

いいえ。本ツールは技術コアのみです。ご利用の cloud client 用コネクタも必要です。

はい。ただし同期するフォルダ/添付が多いと遅くなることがあります。一方、>10k の取引先と約 5k のプロダクトバリアントを同期した環境でも処理は許容範囲だったとお客様から報告があります。

強調すべき点:

1. 同期は、どの項目も失われず同期されるように作られています。速くない場合もあります。FIFO キューと各ジョブのコミットがそれを保証します。
2. 対象数は論理的に制限できます。モデル設定で古い項目の同期を制限できます（例: アーカイブ済み取引先や 2 年前のオーダを同期する意味はありません）。

いいえ。リアルタイム同期を避ける確かな理由があります:

• パフォーマンスの問題。同期がリアルタイムだと、ファイルアップロードのたびに読み込み画面が出ます。

• 競合の問題。2 人のユーザーが同時に項目を変更すると、解決できない状況になり得ます。定期ジョブなら後から直せますが、リアルタイムではキューとして保存する必要があり、ユーザーにとってさらに分かりにくくなります。

• 機能上の問題。特に項目の名前変更と再構成です。逆方向同期ではディレクトリ論理に厳密に依存し、毎回 100% の項目を確認します。更新のたびに行うと毎秒数千リクエストになります。行わなければ変更は失われます。

いいえ、この機能はバージョン 15 以降でのみ利用できます。

はい、cloud client の設定によります。

現行の Odoo Apps Store ポリシーによると:

• バージョン 12.0 以前向けに購入したモジュールは、12.0 までの全バージョンにアクセスできます。
• バージョン 13.0 以降、各モジュールバージョンは個別に購入します。
• バージョンに関係なく、購入するとメジャーバージョン内の すべての更新と不具合修正の権利が得られます。

faOtools チームはこれらのポリシーを管理していません。ご質問は Odoo Apps Store の担当者へ直接お問い合わせください。

最も単純な方法は、Odooストア組み込みのワークフローを使うことです:

1. モジュールのページを開き、Deploy on odoo.sh ボタンをクリックします。

2. その後 GitHub ページにリダイレクトされます。アカウントにログインし、'Create a new repo' をクリックするか既存のものを使います。リポジトリはプライベートにしてください。OPL-1 ライセンスのアプリを公開することは許可されていません。必要なら Odoo.sh プロジェクト用に新しい repo を作成します。

3. 次に odoo.sh に行き、Deploy ボタンをクリックします。ポップアップで決定を送信し、'Continue.' をクリックします。これでインストールが始まります。

これらの手順でプロジェクトの本番ブランチにアプリがインストールされます。他のブランチにデプロイする、またはモジュールを更新する場合は、次の操作を行います:

1. Odooストアからアプリのソースコードをアップロードします。

2. モジュールを必要な GitHub リポジトリにコミットします。アプリのフォルダ/ファイルが無視されていないこと（repo の .gitignore に含まれていないこと）を確認してください。リポジトリは odoo.sh が自動作成し、既定で重要な項目（例: /lib）が含まれることがあります。モジュールのディレクトリ、サブディレクトリ、ファイルを例外なくすべてアップロードしてください。

3. odoo.sh プロジェクトの対象ブランチを Deploy するか、 設定がそうなっている場合は自動ビルドされるまで待ちます。

はい、もちろんです。同時に Odoo は依存関係をすべてカートに自動追加するので、二重払いを避けるには既に購入したツールを除外してください。

赤/オレンジの警告はアプリの機能に影響しません。残念ながら、標準の自動テストがアプリの目的と衝突する動作を想定するため、モジュールが通らないことがあります。たとえば価格計算を変える一方、標準 Odoo モジュールのテストは最終価格を標準アルゴリズムと比較します。

まず、デプロイ済みデータベースの機能を確認してください。すべて正しく動いていますか？

それでも警告が実機能に影響すると考える場合はご連絡のうえ、インストールログ一式とデプロイ済みモジュールの全一覧（コアおよびサードパーティ含む）を送ってください。

いいえ、ツールは 公式の Odoo アプリストア.

残念ながら、個別価格を提示する技術的手段が ありません。 

いいえ、サードパーティアプリは Odoo Online では使えません。残念ながら Odoo SaaS がその可能性をブロックします。

はい、ツールが正しく動くには依存関係に記されたすべてのモジュールが必要です。アプリページの価格には必要な依存関係がすでに含まれています。