{"id":21171602,"url":"https://github.com/0k/oem","last_synced_at":"2025-07-19T15:32:23.368Z","repository":{"id":25938245,"uuid":"29379675","full_name":"0k/oem","owner":"0k","description":"OpenERP/Odoo Manager is general purpose tool for module maker and technical administrators.","archived":false,"fork":false,"pushed_at":"2018-11-21T17:05:22.000Z","size":93,"stargazers_count":3,"open_issues_count":1,"forks_count":4,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-04-05T06:11:52.752Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-2-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/0k.png","metadata":{"files":{"readme":"README.rst","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-01-17T04:25:14.000Z","updated_at":"2018-11-21T17:05:24.000Z","dependencies_parsed_at":"2022-08-02T21:01:08.320Z","dependency_job_id":null,"html_url":"https://github.com/0k/oem","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/0k/oem","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/0k%2Foem","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/0k%2Foem/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/0k%2Foem/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/0k%2Foem/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/0k","download_url":"https://codeload.github.com/0k/oem/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/0k%2Foem/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":264502490,"owners_count":23618617,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-20T16:08:36.566Z","updated_at":"2025-07-09T19:33:00.725Z","avatar_url":"https://github.com/0k.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"=========================\noem\n=========================\n\n.. image:: http://img.shields.io/pypi/v/oem.svg?style=flat\n   :target: https://pypi.python.org/pypi/oem/\n   :alt: Latest PyPI version\n\n.. image:: http://img.shields.io/travis/0k/oem/master.svg?style=flat\n   :target: https://travis-ci.org/0k/oem/\n   :alt: Travis CI build status\n\n.. image:: http://img.shields.io/codecov/c/github/0k/oem.svg?style=flat\n   :target: https://codecov.io/gh/0k/oem/\n   :alt: Test coverage\n\n\n``oem`` is a command line tools to help OpenERP/Odoo module makers and\nserver administrator on common generic tasks.\n\n\nMaturity\n========\n\nDo not use this software for now. These are the first alpha releases.\n\n\nFeatures\n========\n\nusing ``oem``:\n\n- ``oem init`` allows you to create skeletin of new project easily\n- ``oem rec import`` manage your XML data files easily by importing UI modifications.\n\n\nCompatibility\n=============\n\nThis code is python2 only for now.\n\n\nInstallation\n============\n\n..\n   You don't need to download the GIT version of the code as ``oem`` is\n   available on the PyPI. So you should be able to run::\n\n       pip install oem\n\nClassical python libraries dependencies can be installed on debian-like system::\n\n    apt-get update \u0026\u0026 apt-get install python-pip python-dev libxml2-dev libxslt1-dev libz1g-dev\n\nNotice that oem uses ``libxml2-utils``, so you should probably install it also::\n\n    apt-get install libxml2-utils\n\nFor now, because we use specific ``cookiecutter`` and ``ooop`` versions,\nyou should make sure you have the correct dependencies::\n\n    pip install -r requirements.txt\n\nAnd then you can use directly the ``oem`` link, or install it locally::\n\n    python setup.py install\n\n\n\n..\n   If you have downloaded the GIT sources, then you could add install\n   the current version via traditional::\n\n\n..\n   And if you don't have the GIT sources but would like to get the latest\n   master or branch from github, you could also::\n\n       pip install git+https://github.com/0k/oem\n\n   Or even select a specific revision (branch/tag/commit)::\n\n       pip install git+https://github.com/0k/oem@master\n\n\nUsage\n=====\n\n\noem rec import\n--------------\n\nThis command imports records from a running OpenERP/Odoo database to\nXML records that it'll dispatch in files in your module hierarchy to\nfollow conventions. It takes care also, of declaring any new files in\nthe ``data`` section of your  ``__openerp__.py`` if needed.\n\nThis command is aware of any XML records already declared in\nyour module, and will update an existing declaration in-place.\n\nRelations between object are followed if specified and import is then\ncascaded.\n\nThe ``--help`` is complete (as all other commands). Here are\nsome specific example of use on various points.\n\n\nspecifying target database\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\nYou can specify the database through the command line::\n\n   ## import in XML the user ``fabrice`` in database ``db_prod``\n\n   $ oem rec import --db db_prod res.users --name fabrice\n\nPlease note that if you work with the same database for a while\nyou'lll probably want to save the default database to avoid specifying\nit every time::\n\n   $ oem db use db_prod\n   $ oem rec import ir.ui.menu --id 356\n\nThis command will save in your ``~/.oem.rc`` the default db in the key\n``default_db``. If you which to store this information in your module-local\nconfig file you should add ``--local`` as follow::\n\n    $ oem db use db_prod --local\n\nIf you wonder what is your current ``default_db``, you can ask without using any\nargument::\n\n    $ oem db use\n\nIt'll display the current value.\n\n\nimported fields specification\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\nFields that gets imported in XML are configurable::\n\n   ## import partner ``fabrice`` without the fields ``image``, ``ìmage_medium``, ``image_small``\n\n   $ oem rec import res.partner --name fabrice --fields -image,-image_medium,-image_small\n\nYou can setup the default fields that get imported per model for\nspecific module, or globally with the config key\n``rec.import.fields``.  This can be set or modified in your\n``~/.oem.rc`` for global configuration (or ``.oem.rc`` in the root of\nyour module for local configuration).\n\nHere's how to set the previous fields with ``oem config set``::\n\n    oem config set rec.import.fields.'res\\.partner' ,-image,-image_medium,-image_small\n\nNotice 2 shell tricks/caveat when using command line ``oem config set``:\n\n- the model name containes a dot, but ``oem config set`` uses dots to\n  browse into sub-keys. So we need to escape the dot with a slash.\n- second, to avoid having the final argument mistaken with a command\n  line option (due to the leading ``-``), we artificially added a\n  comma ``,`` in front of the list of fields.\n\nThe YAML config entry in the config file will look like this::\n\n  rec:\n    import:\n      fields:\n        res.partner: ',-image,-image_medium'\n\nNote that by default, these are part of the default config file in your\nmodule (installed by ``oem init`` and provided by the default template)::\n\n  rec:\n    import:\n      fields:\n        *: *,-create_uid,-write_uid,-create_date,-write_date,-__last_update\n        ir.actions.act_window: name,type,res_model,view_id,view_type,view_mode,target,usage,domain,context\n\nNote that:\n\n- ``*`` as a model key stands for all models,\n- ``*`` as a field name stand for all fields.\n- You can use ``-`` in front of a field to remove it, and ``+`` (or\n  nothing) to add it.\n\nPlease bear in mind that:\n\n- You cannot remove a required field (import would fail anyway), it'll be ignored.\n- You cannot add read-only field (import would fail anyway). it'll be ignored.\n- You can add complex types as references, many2many, one2many, this will trigger\n  cascading import.\n\n\nOn the command line, the format is\n``[MODEL:]FIELD1[,FIELD2[,...]][;[MODEL2:]FIELD21[,FIELD22[,...]]]``,\nas this might not be so clear, here are detailled explanations:\n\n- fields are separated by ``,``, and use ``-`` or ``+`` in front of their name to remove\n  or add them.\n- use ``MODEL:`` in front of field list to specify their model, otherwise, the\n  current model will be used. So::\n\n    ## explicit field specification on the command line:\n\n    $ oem rec import res.partner --fields res.partner:image,-image_medium\n\n    ## in the following field specification, the model is not specified, so\n    ## it'll be defaulted to current model being imported: ``res.partner``.\n\n    $ oem rec import res.partner --fields image,-image_medium\n\n- you can specify several fields specification for several models by\n  using semicolon ``;`` for separating them. This can be useful when\n  cascading through models thanks to one2many fields or any other\n  complex field.\n\nCommand line values have priority over config file values. You should probably\nstore your field specification instead of using command line to avoid complexity.\nCommand line specification are nice for one-shot imports.\n\n\nfile dispatching\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\nYour records gets dispatched in files, but you can specify where you want them to be\ncreated, thanks to ``--out`` option::\n\n   ## import partner ``fabrice`` without the fields ``image``, ``ìmage_medium``, ``image_small``\n\n   $ oem rec import res.partner --name fabrice --out personnel/fabrice.xml\n\nSubdirectory will be created accordingly, and the new file will be\nadded in ``__openerp__.py``.  However, be warned that if your record\nhappen to already be stored in XML, it will be updated in place and\nyour ``--out XXX`` option won't be used. (this might change in the\nfuture however)\n\nYour records gets dispatched in files in your module according to a\ndispatching specification. As usual, this can be set for one module or\nglobally through the ``.oem.rc`` files. The sub-key concerned is\n``rec.import.dispatch``. Here's the default value from the the default\n``.oem.rc`` file::\n\n    rec:\n      import:\n        dispatch:\n          '*': data/%(_model_underscore)s.xml\n          ir.actions.act_url: actions/act_url.xml\n          ir.actions.act_window: actions/act_window.xml\n          ir.actions.actions: actions/action.xml\n          ir.actions.client: actions/client.xml\n          ir.actions.server: actions/server.xml\n          ir.ui.menu: menu.xml\n          ir.ui.views: views/view.xml\n\nit's a ``MODEL: FILENAME`` dictionary. The ``*`` for model stands for\nall models. The filename specifier can use python dictionary\ninterpolation keys as it'll be interpolated with a dict containing the\nfield, values of the current record to be dispatched with some\nadditional metadata information as:\n\n- ``_model`` for the model of the current record.\n- ``_model_underscore`` for the model of the current record with\n  underscore inplace of dots.\n\nSo for instance to add a new dispatching place, you could use ``oem config set``::\n\n    oem config set rec.import.dispatch.'res\\.partner' \"personnel/%(name).xml\"\n\n\n\nContributing\n============\n\nAny suggestion or issue is welcome. Push request are very welcome,\nplease check out the guidelines.\n\n\nPush Request Guidelines\n-----------------------\n\nYou can send any code. I'll look at it and will integrate it myself in\nthe code base and leave you as the author. This process can take time and\nit'll take less time if you follow the following guidelines:\n\n- check your code with PEP8 or pylint. Try to stick to 80 columns wide.\n- separate your commits per smallest concern.\n- each commit should pass the tests (to allow easy bisect)\n- each functionality/bugfix commit should contain the code, tests,\n  and doc.\n- prior minor commit with typographic or code cosmetic changes are\n  very welcome. These should be tagged in their commit summary with\n  ``!minor``.\n- the commit message should follow gitchangelog rules (check the git\n  log to get examples)\n- if the commit fixes an issue or finished the implementation of a\n  feature, please mention it in the summary.\n\nIf you have some questions about guidelines which is not answered here,\nplease check the current ``git log``, you might find previous commit that\nwould show you how to deal with your issue.\n\n\nLicense\n=======\n\nCopyright (c) 2018 Valentin Lab.\n\nLicensed under the `BSD License`_.\n\n.. _BSD License: http://raw.github.com/0k/oem/master/LICENSE\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2F0k%2Foem","html_url":"https://awesome.ecosyste.ms/projects/github.com%2F0k%2Foem","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2F0k%2Foem/lists"}