I am confused about why we need to make a custom_addons directory, however we already have addons directory in files. I downloaded odoo 13 (windows).
Mostly to make a separation between multiple code bases, for example, keeping Odoo provided addons directory separate from your customized addons directory. Let's say you want to use addons from multiple third party repositories, you can keep each repositories code base in separate directory and add the paths in addons_path in odoo.conf file.
Related
I am currently having the same issue that melezhik has explained in his ticket at the bailador project. https://github.com/Bailador/Bailador/issues/309.
I want to write a module App::Something that is Cro based which should ship a few files and folders. Taken from the comments on this post the $?RESOURCE "flattens" the contents of directory down to single files.
Do you have a smart idea how to provide access to folder structures shipped in modules?
I am using Odoo v.8. I want to find out where Odoo finds information where the modules are, to load them. I am aware there is a variable addons_path in the file openerp-server.conf. The only file I have found the variable in is opt/odoo/odoo/debian/openerp-server.conf. It has the following value:
addons_path = /usr/lib/python2.7/dist-packages/openerp/addons
However, the Odoo application is using modules from "/opt/odoo/odoo/addons" path. Where the Odoo retrieves this information from? If I have a new directory with new modules, where I can update the path? I have updated addons_path in opt/odoo/odoo/debian/openerp-server.conf with new modules path, but Odoo still cannot see the modules in Settings/Update Modules List. I have restarted the server.
Thanks for your help!
You can add to the addons_path directive in openerp-server.conf, (separate paths with a comma) or you can use --addons= if starting your server from the command line.
Odoo tries to initializes a set of paths to be loaded from the base addons directory. Check the code for Odoo system path
So, with the help of this method, it loads the basic addons directory and other directories that are added by addons_path.
Generally, we use addons_path at odoo-server.conf and save our addons directory path at it.
Note: the path must contain atleast one OpenERP/Odoo module in it.
As of Odoo V8, the "default" addons_path in the odoo-server.conf file should read as follows (assuming you installed Odoo in the "/opt/odoo" path, otherwise change accordingly):
addons_path = /opt/odoo/addons
If you also need to add another "custom" folder for additional modules, separate those with a comma, like this:
addons_path = /opt/odoo/addons,/opt/odoo/custom_modules
I am trying to understand the templating system. There is a /templating directory with following README:
It is not advised to make local modifications to those files after installation, as they might be lost during the installation of a new Trac version.
As an alternative, you can copy the templates you want to modify and place them in the templates/ directory of your Trac environment or in the location specified in the trac.ini file under the [inherit] templates_dir setting (the former having precedence over the latter).
This would be nice - I could have templates for my project nicely separated in the same path as my project. But this directory contains only part of the templates and for example ticket templates modification is impossible within this path.
So what is the correct way to modify Trac templates?
Thanks!
It is discouraged in general, because local/custom templates take precedence, and this could come in the way, if upstream releases have significant changes. You'll never get warned about a changed template and you'll have to re-base your template customization on-top of each new template.
Anyway, start from a fresh template copy from source. Templates are to be found in sub-directories templates of the respective Trac realm (i.e. ticket/templates, versioncontrol/templates, wiki/templates) and put it to all directly into <env>/templates (initially empty) or for reusing them in multiple Trac environments as per your [inherit] configuration.
Since Trac-0.11 Trac uses the Genshi template engine. See it's own wiki documentation about the available syntax.
I use the deb file for production and the source for development.Is this the correct way to do things?
I think that the deb might have certain optimizations(pyo or pyc) for production environment.
But since I have to move my custom modules, one at a time to the production,I find it increasingly difficult.
The actual addons path is here
(1) /usr/share/pyshared/openerp/addons
But the init.d points to
(2) /usr/lib/pymodules/python2.7/openerp/addons
In some modules the __init__.py is in 1 (eg: web_rpc)
and for some its in 2 (eg: hr)
What the actual difference btw
http://nightly.openerp.com/6.1/nightly/src/
and
http://nightly.openerp.com/6.1/nightly/deb/
I haven't tried the deb files, because we use the Ubuntu all-in-one script from openerpappliance.com. It downloads the source from Launchpad and then runs the deployment scripts for you. It will also do updates after you've installed.
We're very happy with the 5.0 version, but we haven't tried the 6.1 version, yet.
you can do with 6.1 is you can give multiple addons path to the your config file in comma separated , or else you can create link in addons folder for your customized folder while you can keep cumized module where you want, just put link(shortcut) to the addon sfoderl of your. this will give you flexibility.
Thank YOu
I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.