Exibir código-fonte para Estrutura - Módulo


[[Ficheiro:Modulosopenerp.png|thumb|Estrutura módulo]]
Um módulo poderá conter os seguintes elementos:

'''Objeto de Negócios :''' declarado como classes Python estendendo o osv.Model classe, a persistência destes recursos é completamente gerenciado pelo ORM do OpenERP.

'''Dados :''' Os arquivos XML / CSV com meta-dados (pontos de vista e declaração de fluxos de trabalho), os dados de configuração (módulos de parametrização) e dados de demonstração (opcional, mas recomendado para o teste),

'''Relatórios :''' RML (formato XML). HTML / MAKO ou OpenOffice modelos de relatório, a ser mesclado com qualquer tipo de dados de negócios, além de gerar HTML, ODT ou relatórios em PDF.

Cada módulo está contido em seu próprio diretório dentro ou o / bin / addons do servidor ou outro diretório de addons, configurado na instalação do servidor. Para criar um novo módulo, por exemplo, o módulo 'OpenAcademy', são necessárias as seguintes etapas:

* Criar um<pre>openacademy</pre>subdiretório no diretório de origem / addons

* Criar o arquivo de importação módulo <pre>__init__.py</pre>

* Criar o arquivo Manifield módulo <pre>__openerp__.py</pre>

* Criar Python arquivos contendo objetos

* Criar. xml segurando os dados do módulo, como visualizações, entradas de menu ou dados de demonstração

* Opcionalmente, criar relatórios ou workflows

=='''Arquivo de importação Python __ init__.py'''== 

O <pre>__init__.py</pre> arquivo é o arquivo de importação Python, porque um módulo OpenERP também é um módulo Python regular. O arquivo deve importar todos os outros arquivos python ou submódulos.

Por exemplo, se um módulo contém um único arquivo python chamado <pre>openacademy.py</pre> , o arquivo deve ser parecido:

openacademy importação

=='''Arquivo de manifesto __ openerp__.py'''== 

No diretório do módulo criado, você deve adicionar um <pre>__openerp__.py</pre> arquivo. Esse arquivo, que deve ser um dicionário Python literal, é responsável por

determinar os arquivos XML que serão analisados durante a inicialização do servidor, e também para
determinar as dependências do módulo criado.
declarar metadados adicionais
Este arquivo deve conter um dicionário Python com os seguintes valores:
<pre>name        O nome do módulo em Inglês.      
version          A versão do módulo. 
summary          resumo descrição ou palavras-chave 
description      A descrição do módulo (texto).
category         A categoria do módulo 
author           O autor do módulo.
website          URL do site do módulo
license          A licença do módulo (default: AGPL-3).
depends          Lista de módulos em que este módulo depende ao lado de base. 
data             Lista de arquivos XML para carregar quando o módulo é instalado ou atualizado.
demo             Lista de arquivos xml adicional. para carregar quando o módulo é 
                 instalado ou atualizado e bandeira de demonstração está ativo.
installable      Verdadeiro ou Falso. Determina se o módulo é instalado 
                 ou não.
auto_install     Verdadeiro ou Falso (padrão: False). Se definido como "É verdade", o 
                 módulo é um link. Ele será instalado assim 
                 como todas as suas dependências estão instaladas.</pre>


Para o <pre>openacademy</pre> módulo, aqui está um exemplo de <pre>__openerp__.py</pre> arquivo de declaração:


<pre>{
    'name' : "OpenAcademy",
    'version' : "1.0",
    'author' : "OpenERP SA",
    'category' : "Tools",
    'depends' : ['mail'],
    'data' : [
        'openacademy_view.xml',
        'openacademy_data.xml',
        'report/module_report.xml',
        'wizard/module_wizard.xml',
    ],
    'demo' : [
        'openacademy_demo.xml'
    ],
    'installable': True,
}</pre>

=='''Objetos'''==
Todos os recursos são objetos OpenERP: faturas, parceiros. Metadados são também objeto também: menus, ações, relatórios ... Nomes de objeto são hierárquicos, como nos exemplos a seguir:

----

*account.transfer: a transferência de dinheiro
*account.invoice: uma factura
*account.invoice.line: uma linha de factura
----

Geralmente, a primeira palavra é o nome do módulo: conta, estoque, venda.

Aqueles objeto são declaradas em python ser subclasse osv.Model

O ORM do OpenERP é construído sobre PostgreSQL. Assim, é possível consultar o objeto usado pelo OpenERP utilizando a interface de objeto (ORM) ou usando diretamente instruções SQL.

Mas é perigoso para escrever ou ler diretamente no banco de dados PostgreSQL, como você vai atalho passos importantes, como as restrições de verificação ou de modificação de fluxo de trabalho.

=='''Arquivos XML''' ==

Arquivos XML localizados no diretório do módulo são usados para inicializar ou atualizar o banco de dados quando o módulo é instalado ou atualizado. Eles são usados para muitas finalidades, dentre as quais podemos citar:

----

*inicialização e declaração de dados de demonstração,
*declaração pontos de vista,
*declaração relatórios,
*declaração workflows.

----

Estrutura geral de arquivos XML OpenERP é mais detalhado no XML de dados de serialização seção. Olha aqui, se você estiver interessado em aprender mais sobre a inicialização e de demonstração de declaração de dados de arquivos XML. A seção a seguir só estão relacionados com XML específico para ações, entradas do menu, relatórios, assistentes e fluxos de trabalho de declaração.

Os dados podem ser inseridos ou atualizados nas tabelas do PostgreSQL correspondentes aos objetos OpenERP usando arquivos XML. A estrutura geral de um ficheiro XML OpenERP é como se segue:

<pre><?xml version="1.0"?>
<openerp>
  <data>
    <record model="model.name_1" id="id_name_1">
      <field name="field1"> "field1 content" </field>
      <field name="field2"> "field2 content" </field>
      (...)
    </record>
    <record model="model.name_2" id="id_name_2">
        (...)
    </record>
    (...)
  </data>
</openerp>
</pre>

Grave Tag 

Descrição

A adição de novos dados é feita com o tag de ficha. Este leva um atributo obrigatório: Modelo. Modelo é o nome do objeto em que a inserção tem de ser feito. O registro de marca também pode ter um atributo opcional: id. Se este atributo é dado, uma variável deste nome pode ser usado mais tarde, no mesmo arquivo, para fazer referência ao ID do recurso recém-criado.

A tag registro pode conter marcas de campo. Eles indicam os campos de valor do registro. Se um campo não for especificado, o valor padrão será usado.

A tag campo do registro'

Os atributos para a tag campo são os seguintes:

'''Nome : obrigatório'''
o nome do campo

'''eval : opcional'''
expressão python que indica o valor a adicionar

'''ref'''
referência a um ID definido neste arquivo

'''modelo'''
modelo a ser pesquisado na busca

'''pesquisa'''
uma consulta

Exemplo
<pre>
<record model="ir.actions.report.xml" id="l0">
     <field name="model">account.invoice</field>
     <field name="name">Invoices List</field>
     <field name="report_name">account.invoice.list</field>
     <field name="report_xsl">account/report/invoice.xsl</field>
     <field name="report_xml">account/report/invoice.xml</field>
</record>
</pre>
Vamos analisar um exemplo retirado da fonte OpenERP (base_demo.xml no módulo de base):
<pre>
<record model="res.company" id="main_company">
    <field name="name">Tiny sprl</field>
    <field name="partner_id" ref="main_partner"/>
    <field name="currency_id" ref="EUR"/>
</record>
</pre>
<pre>
<record model="res.users" id="user_admin">
    <field name="login">admin</field>
    <field name="password">admin</field>
    <field name="name">Administrator</field>
    <field name="signature">Administrator</field>
    <field name="action_id" ref="action_menu_admin"/>
    <field name="menu_id" ref="action_menu_admin"/>
    <field name="address_id" ref="main_address"/>
    <field name="groups_id" eval="[(6,0,[group_admin])]"/>
    <field name="company_id" ref="main_company"/>
</record>
</pre>

Este último registro define o usuário admin:

----

*Os campos de login, senha, etc, são simples.
*O atributo ref permite preencher as relações entre os registros:

----

<pre><field name="company_id" ref="main_company"/></pre>

O campo company_id é uma relação muitos-para-um a partir do objeto de usuário para o objeto da empresa e main_company é o id de associado.

----

*O eval atributo permite colocar algum código python no xml: aqui o campo groups_id é um many2many. Para essa área ", [(6,0, [group_admin])]" significa: Remova todos os grupos associados ao usuário atual e usar a lista [group_admin] como os novos grupos associados (e group_admin é o id de outro recorde ).
*A pesquisa atributo permite localizar o registro para associar quando você não sabe o seu id xml. Assim, você pode especificar um critério de pesquisa para localizar o registro desejado. O critério é uma lista de tuplas da mesma forma que para o método de busca predefinido. Se existem vários resultados, arbitrária será escolhida (o primeiro):

----

<pre><field name="partner_id" search="[]" model="res.partner"/></pre>

Este é um exemplo clássico do uso de pesquisa em dados de demonstração: aqui nós realmente não me importo sobre qual o parceiro que deseja usar para o teste, por isso damos uma lista vazia. Observe o modelo de atributo, é obrigatório.

Função tag 

A tag função pode conter outras tags de função.

'''modelo : obrigatória'''
O modelo a ser usado

'''Nome : obrigatório'''
o nome da função dada

'''eval'''
deve avaliar a lista de parâmetros do método a ser chamado, excluindo cr e uid

Exemplo
<pre><function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/></pre>

== '''Visualizações''' ==

As vistas são uma forma de representar os objetos no lado do cliente. Eles indicam para o cliente como para dispor os dados provenientes dos objetos na tela.

Existem dois tipos de pontos de vista:

----

*formar visualizações
*visualizações de árvore

----

As listas são simplesmente um caso particular de pontos de vista de árvore.



Um mesmo objeto pode ter vários pontos de vista: a primeira exibição definida de um tipo ( árvore, forma ...) será usado como a visualização padrão para este tipo. Dessa forma, você pode ter uma visão de árvore padrão (que atuará como o ponto de vista de um one2many) e uma visão especializada, com mais ou menos informações que aparecerão quando um duplo clique em um item de menu. Por exemplo, os produtos têm várias vistas de acordo com as variantes de produto.

Visualizações são descritos em XML.

Se nenhum ponto de vista tem sido definido para um objeto, o objeto é capaz de gerar uma visão para representar a si mesmo. Isso pode limitar o trabalho do desenvolvedor, mas resulta em menos visualizações ergonômicas.

'''Exemplo de uso''' 

Quando você abre uma factura, aqui é a cadeia de operações, seguido pelo cliente:

----

*Uma ação pede para abrir a fatura (que dá os dados do objeto (account.invoice), a visão, o domínio (por exemplo, apenas as faturas não pagas)).
*O cliente pede (com XML-RPC) para o servidor que vistas são definidas para o objeto da fatura e quais são os dados que ele deve mostrar.
*O cliente exibe o formulário de acordo com a visão

----

'''Para desenvolver novos objetos'''

A concepção de novos objetos é restrito ao mínimo necessário: criar os objetos e, opcionalmente, criar as vistas para representá-los. As tabelas do PostgreSQL não tem que ser escrito à mão, porque os objetos são capazes de criar automaticamente eles (ou adaptá-los no caso de existir).

'''''Relatórios''''' 

OpenERP utiliza um sistema de comunicação flexível e poderosa. Os relatórios são gerados tanto em PDF ou em HTML. Os relatórios são projetados sobre o princípio da separação entre a camada de dados ea camada de apresentação.

Os relatórios são descritos mais detalhadamente no Relatório capítulo.

'''''Fluxo de Trabalho'''''

Os objetos e os pontos de vista permitem definir novas formas de maneira muito simples, as listas / árvores e as interações entre eles. Mas isso não é suficiente, você deve definir a dinâmica desses objetos.

Alguns exemplos:

----

*uma ordem de venda confirmada deve gerar uma fatura, de acordo com certas condições
*uma fatura paga deve, apenas sob certas condições, iniciar a ordem de envio

----

Os fluxos de trabalho de descrever essas interações com gráficos. Um ou vários fluxos de trabalho podem estar associados aos objetos. Os fluxos de trabalho não são obrigatórios, alguns objetos não têm fluxos de trabalho.

Abaixo está um exemplo de fluxo usado para ordens de venda. Deve gerar faturas e os embarques de acordo com certas condições.

Neste gráfico, os nós representam as ações a serem feitas:

----

*criar uma fatura,
*cancelar a ordem de venda,
*gerar a ordem de envio, ...

----

As setas são as condições;

----

*espera para a validação do pedido,
*fatura paga,
*clique no botão cancelar, ...

----

Os nós quadrados representam outros fluxos de trabalho;

*a factura
*o transporte

'''''i18n''''' 

Alterado na versão 5.0.

Cada módulo tem seu próprio <pre>i18n</pre> pasta. Além disso, OpenERP pode agora lidar com <pre>.po</pre> arquivos como formato de importação / exportação. Os arquivos de tradução de idiomas instalados são automaticamente carregados durante a instalação ou atualização de um módulo.

As traduções são geridos pelo [https://translations.launchpad.net/openobject Interface web Launchpad] . Aqui, você encontrará a lista de projetos traduzíveis.