OwnCloud / NextCloud Odoo Integration v.14

No, this feature is available only from version 15. Prior to that version, the module works with the pre-defined structure of folders:

1. Odoo - a core folder for sync

2. Models - folders for each Odoo document type. For example, 'Projects', 'Partners'. Distinguished by domain there might be more specific folders: e.g., 'Customer 1 Projects', 'Projects of the Customer 2', 'Internal Projects', etc.

3. Objects - folders for each document, e.g. 'Project 1' or 'Customer 1'

4. Files and folders related to this Odoo document to be synced.

As a result you may have for instance:

• Odoo / Projects / Project 1 / files and folders related to the  project 1

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

• Odoo / Customers / Customer 1 / files and folders related to the customer 1

This structure is always flat, meaning that there are only those levels of hierarchy. Thus, it is correct that various document types can't be done within the same structure. Within the folder 'Customer 1' we can't keep the files related both to sale orders, invoices, and projects. Each of those document type has an own (or a few own) folders. Otherwise, we will not have a chance to make backward synchronisation, since there would be no criteria to rely upon.

No, the tool relies upon a single user end point. It means that all sync processes are done under a single cloud admin (app). Access rights for created folders / files are not automatized. You should administrate those rights in your cloud storage solution.

The app assumes that the binary content of attachments is kept in Cloud Client instead of the Odoo server. So, such attachments in Odoo become of the URL type, and you may any time access them either from the attachments box or from the Cloud Client.

After the setup, no manual actions are required, as the synchronisation is fully automatic. Just decide which Odoo document types should be synced and set up a related model to sync for each of those (Customers, Sale or Purchase Orders, Tasks, Projects, etc.).

Yes, you can. To that goal, prepare a rule for each, and then those apply filters: for example by type of a project.

Try to make filters self-exclusive in order a document can be definitely assigned. For instance, 'customer but not supplier', 'supplier but not customer'. Otherwise, a specific document folder would jump from one model to another.

No, the tool is only a technical core. You also need the connector for your cloud client.

Yes, although in the case of many folders/attachments that need to sync, the process might be slow. Simultaneously, our clients reported the environments with >10k partners and ~5k product variants to be synced, and the processes were acceptable.

A few points to emphasize:

1. The sync is constructed so that any item will be synced and not lost, although it might not be fast. It is guaranteed by first-in-first-out queues and by each job committed.
2. The number of objects might be limited logically. The models' configuration lets you restrict the sync of obsolete items (e.g., there is no sense in syncing archived partners or orders done 2 years ago).

No. We have strong reasons to avoid real time sync:

• Performance issues. In case a sync is real time, each file upload will result in the loading screen.

• Conflict issues. If 2 users simultaneously change an item, it might lead to unresolved situations. In case of regular jobs we can fix it afterwards, while in case of real time we would need to save it as some queue, and it will be even more misleading for users.

• Functionality issues. In particular, renaming and restructuring of items. In the backward sync the tool strictly relies upon directories' logic, and during each sync 100% of items are checked. In case it is done after each update, it will be thousands of requests per second. If not: changes would be lost.

You may assign your name for models' directories (sale orders, opportunities, suppliers, etc.) for any document type.

For objects' folders (SO-001, John Smith, etc.), the tool relies upon the Odoo method to construct a display name for this document type. However, you can change that by defining the name expression. The exact syntax for Odoo email templates is used. 

No, this feature becomes available only from version 15.

Yes, depending on your cloud client configuration.

No, the tags are not synchronized. We considered this feature previously, but made a decision not to introduce such a feature due to a number of reasons:

• The connector library doesn't support getting or updating OwnCloud tags

• Odoo attachments do not have the attribute 'tags' and it is not fully clear when those tags would be assigned to users.

• Since the app provides bilateral sync, there might be critical conflicts during sync which would be difficult to resolve.

According to the current Odoo Apps Store policies:

• Every module bought for version 12.0 and prior gives you access to all versions up to 12.0.
• Starting from version 13.0, every module version should be purchased separately.
• Disregarding the version, purchasing a tool grants you a right to all updates and bug fixes within a major version.

Please note that the faOtools team does not control those policies. For all questions, please contact the Odoo Apps Store representatives directly.

The most straightforward approach is to use the Odoo store's built-in workflow:

1. Open the module's page and click the button Deploy on odoo.sh

2. After that, you will be redirected to the GitHub page. Log in to your account, then click 'Create a new repo' or use an existing one. Please ensure your repository is private. It is not permitted to publish the apps under the OPL-1 license. If necessary, create a new repo for your Odoo.sh project

3. Then, go to odoo.sh and click the Deploy button. In the pop-up window, submit the decision and click 'Continue.' This action will trigger the installation process.

These steps will install the app for your project's production branch. If you want to deploy the apps for other branches or update the module, you should undertake the following actions:

1. Upload the source code for the app from the Odoo store

2. Commit the module to a required GitHub repository. Ensure none of the app folders/files are ignored (i.e., not included in your repo's .gitignore). Repositories are automatically created by odoo.sh and may include some crucial items by default (e.g., /lib). You should upload all module directories, subdirectories, and files without exceptions

3. Deploy a target branch of the odoo.sh project or, if your settings assume that, wait until it is automatically built.

Yes, sure. Simultaneously, Odoo automatically adds all dependencies to a cart, so you should exclude previously purchased tools to avoid double payment.

A red/orange warning does not influence the app's features. Regretfully, sometimes our modules do not pass standard automatic tests since the latter assume behaviour that conflicts with our app's goals. For example, we change the price calculation, while the standard Odoo module tests compare the final price to a standard algorithm.

So, first of all, please check the deployed database features. Does everything work correctly?

If you still assume that the warning influences real features, please contact us and forward full installation logs and the full list of deployed modules (including core and third-party ones).

No, we only distribute the tools through the official Odoo apps store.

Regretfully, we do not have the technical means to provide individual prices. 

No, third-party apps can not be used on Odoo Online. Unfortunately, Odoo SaaS blocks such a possibility.

Yes, our tool requires all modules marked in dependencies to work correctly. The price marked on the app page already includes all necessary dependencies.