[Merge]Merge lp:openobject-server

bzr revid: vja@tinyerp.com-20130417094709-l6butz9hlq27ftd1

MANIFEST.in

@@ -7,7 +7,7 @@ graft win32
 include README
 include LICENSE
 include MANIFEST.in
-include gunicorn.conf.py
+include openerp-wsgi.py
 include openerp-server
 include setup*
 global-exclude *pyc *~    # Exclude possible garbage from previous graft.

debian/control

@@ -19,6 +19,7 @@ Depends:
  python-docutils,
  python-feedparser,
  python-gdata,
+ python-imaging,
  python-jinja2,
  python-ldap,
  python-libxslt1,
@@ -46,12 +47,12 @@ Depends:
 Conflicts: tinyerp-server, openerp-server, openerp-web
 Replaces: tinyerp-server, openerp-server, openerp-web
 Recommends:
- graphviz, ghostscript, postgresql, python-imaging, python-matplotlib
+ graphviz, ghostscript, postgresql, python-matplotlib, poppler-utils
 Description: OpenERP Enterprise Resource Management
  OpenERP, previously known as TinyERP, is a complete ERP and CRM. The main
  features are accounting (analytic and financial), stock management, sales and
  purchases management, tasks automation, marketing campaigns, help desk, POS,
  etc. Technical features include a distributed server, flexible workflows, an
- object database, a dynamic GUI, customizable reports, and NET-RPC and XML-RPC
- interfaces.
+ object database, a dynamic GUI, customizable reports, and an XML-RPC
+ interface.
 

debian/openerp.init

@@ -17,55 +17,46 @@ DAEMON=/usr/bin/openerp-server
 NAME=openerp-server
 DESC=openerp-server
 CONFIG=/etc/openerp/openerp-server.conf
-LOGFILE=/var/log/openerp-server.log
+LOGFILE=/var/log/openerp/openerp-server.log
 USER=openerp
 
 test -x ${DAEMON} || exit 0
 
 set -e
 
+do_start () {
+    echo -n "Starting ${DESC}: "
+    start-stop-daemon --start --quiet --pidfile /var/run/${NAME}.pid --chuid ${USER} --background --make-pidfile --exec ${DAEMON} -- --config=${CONFIG} --logfile=${LOGFILE}
+    echo "${NAME}."
+}
+
+do_stop () {
+    echo -n "Stopping ${DESC}: "
+    start-stop-daemon --stop --quiet --pidfile /var/run/${NAME}.pid --oknodo
+    echo "${NAME}."
+}
+
 case "${1}" in
-	start)
-		echo -n "Starting ${DESC}: "
+    start)
+        do_start
+        ;;
 
-		start-stop-daemon --start --quiet --pidfile /var/run/${NAME}.pid \
-			--chuid ${USER} --background --make-pidfile \
-			--exec ${DAEMON} -- --config=${CONFIG} \
-			    --logfile=${LOGFILE}
+    stop)
+        do_stop
+        ;;
 
-		echo "${NAME}."
-		;;
+    restart|force-reload)
+        echo -n "Restarting ${DESC}: "
+        do_stop
+        sleep 1
+        do_start
+        ;;
 
-	stop)
-		echo -n "Stopping ${DESC}: "
-
-		start-stop-daemon --stop --quiet --pidfile /var/run/${NAME}.pid \
-			--oknodo
-
-		echo "${NAME}."
-		;;
-
-	restart|force-reload)
-		echo -n "Restarting ${DESC}: "
-
-		start-stop-daemon --stop --quiet --pidfile /var/run/${NAME}.pid \
-			--oknodo
-
-		sleep 1
-
-		start-stop-daemon --start --quiet --pidfile /var/run/${NAME}.pid \
-			--chuid ${USER} --background --make-pidfile \
-			--exec ${DAEMON} -- --config=${CONFIG} \
-			    --logfile=${LOGFILE}
-
-		echo "${NAME}."
-		;;
-
-	*)
-		N=/etc/init.d/${NAME}
-		echo "Usage: ${NAME} {start|stop|restart|force-reload}" >&2
-		exit 1
-		;;
+    *)
+        N=/etc/init.d/${NAME}
+        echo "Usage: ${NAME} {start|stop|restart|force-reload}" >&2
+        exit 1
+        ;;
 esac
 
 exit 0

debian/openerp.postinst

@@ -12,9 +12,9 @@ case "${1}" in
         chown openerp:openerp /etc/openerp/openerp-server.conf
         chmod 0640 /etc/openerp/openerp-server.conf
         # Creating log file
-        touch /var/log/openerp-server.log
-        chown openerp:openerp /var/log/openerp-server.log
-        chmod 0640 /var/log/openerp-server.log
+        mkdir -p /var/log/openerp/
+        chown openerp:openerp /var/log/openerp
+        chmod 0750 /var/log/openerp
         # Creating local storage directory
         mkdir -p /var/lib/openerp/filestore
         chown openerp:openerp -R /var/lib/openerp

debian/openerp.postrm

@@ -6,10 +6,11 @@ case "${1}" in
     remove)
         deluser --quiet --system "openerp" || true
         delgroup --quiet --system --only-if-empty "openerp" || true
+        find /var/lib/openerp -path '/var/lib/openerp/*' ! -path '/var/lib/openerp/filestore*' -delete
         ;;
 
     purge)
-        rm -rf /var/lib/openerp-server
+        rm -rf /var/lib/openerp
         ;;
 
     upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)

doc/01_getting_started.rst

@@ -103,9 +103,6 @@ General Options
   --logfile=LOGFILE                   file where the server log will be stored
   -n INTERFACE, --interface=INTERFACE specify the TCP IP address
   -p PORT, --port=PORT                specify the TCP port
-  --net_interface=NETINTERFACE        specify the TCP IP address for netrpc
-  --net_port=NETPORT                  specify the TCP port for netrpc
-  --no-netrpc                         disable netrpc
   --no-xmlrpc                         disable xmlrpc
   -i INIT, --init=INIT                init a module (use "all" for all modules)
   --without-demo=WITHOUT_DEMO         load demo data for a module (use "all" for all modules)

doc/02_architecture.rst

@@ -1,6 +1,6 @@
-========================================
+============
 Architecture
-========================================
+============
 
 OpenERP as a multitenant three-tiers architecture
 =================================================
@@ -180,6 +180,7 @@ OpenERP follows the MVC semantic with
 
 Network communications and WSGI
 ===============================
+
 OpenERP is an HTTP web server and may also be deployed as an WSGI-compliant
 application.
 
@@ -207,3 +208,45 @@ As such, it can be run as a stand-alone HTTP server or embedded inside OpenERP.
 The HTTP namespaces /openerp/ /object/ /common/ are reserved for the XML-RPC
 layer, every module restrict it's HTTP namespace to /<name_of_the_module>/
 
+Process model
+=============
+
+In the past, the OpenERP server was using threads to handle HTTP requests
+concurrently or to process cron jobs. Using threads is still the default
+behavior when running the ``openerp-server`` script but not the recommended
+one: it is in fact recommended to use the ``--workers`` option.
+
+By using the ``--workers`` option, the OpenERP server will spawn a fixed number
+of processes instead of spawning a new thread for each incoming request.
+
+This has a number of advantages:
+
+ - Processes do not suffer from CPython's Global Interpreter Lock.
+ - Processes can be gracefully recycled while requests are still handled by the
+   server.
+ - Resources such as CPU time and memory made available to a process can be
+   monitored on a per-process basis.
+
+When using the ``--workers`` options, two types of processes may be spawned:
+web process, and cron process.
+
+.. versionadded:: 7.1
+
+.. _longpolling-worker:
+
+When using the ``--workers`` options, three types of processes may be spawned:
+web process, and cron process, just as previsouly, but also an evented (using
+gevent) web process is started. It is used for long-polling as needed by the
+upcoming Instant Messaging feature. As for now, that process is listening on a
+different port than the main web processes. A reverse proxy (e.g. Nginx) to
+listen on a unique port, mapping all requests to the normal port, but mapping
+the ``/longpolling`` route to the evented process is necessary (the web
+interface cannot issue requests to different ports).
+
+(It is possible to make the threaded server evented by passing the ``--gevent``
+flag.)
+
+The goal is to drop support for the threaded model, and also make all web
+processes evented; there would be no more distinction between "normal" and
+"longpolling" processes. For this to happen, further testing is needed.
+

doc/03_module_dev.rst

@@ -13,3 +13,4 @@ Modules
    03_module_dev_04
    03_module_dev_05
    03_module_dev_06
+   report-declaration

doc/changelog.rst

@@ -0,0 +1,23 @@
+.. _changelog:
+
+Changelog
+=========
+
+`trunk`
+-------
+
+- Almost removed ``LocalService()``. For reports,
+  ``openerp.osv.orm.Model.print_report()`` can be used. For workflows, see
+  :ref:`orm-workflows`.
+- Removed support for the ``NET-RPC`` protocol.
+- Added the :ref:`Long polling <longpolling-worker>` worker type.
+- Added :ref:`orm-workflows` to the ORM.
+- Added :ref:`routing-decorators` to the RPC and WSGI stack.
+- Removed support for ``__terp__.py`` descriptor files.
+- Removed support for ``<terp>`` root element in XML files.
+- Removed support for the non-openerp namespace (e.g. importing ``tools``
+  instead of ``openerp.tools`` in an addons).
+- Add a new type of exception that allows redirections:
+  ``openerp.exceptions.RedirectWarning``.
+- Give a pair of new methods to ``res.config.settings`` and a helper to make
+  them easier to use: ``get_config_warning()``.

doc/deployment-mod-wsgi.rst

@@ -0,0 +1,73 @@
+.. _using-mod-wsgi:
+
+Deploying with ``mod_wsgi``
+===========================
+
+``mod_wsgi`` makes it possible to run a WSGI_ application (such as OpenERP)
+under the Apache_ HTTP server.
+
+.. _WSGI: http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface
+.. _Apache: https://httpd.apache.org/
+
+Summary
+-------
+
+Similarly to :doc:`deployment-gunicorn`, running OpenERP behind Apache with
+``mod_wsgi`` requires to modify the sample ``openerp-wsgi.py`` script. Then
+that Python script can be set in the Apache configuration.
+
+Python (WSGI) application
+-------------------------
+
+Apache needs a Python script providing the WSGI application. By default the
+symbol looked up by Apache is ``application`` but it can be overidden with the
+``WSGICallableObject`` directive if necessary. A sample script
+``openerp-wsgi.py`` is provided with OpenERP and you can adapt it to your
+needs. For instance, make sure to correctly set the ``addons_path``
+configuration (using absolute paths).
+
+.. note ::
+  The script provided to Apache has often the extension ``.wsgi`` but the
+  ``openerp-wsgi.py`` script will do just as fine.
+
+Apache Configuration
+--------------------
+
+In Apache's configuration, add the following line to activate ``mod_wsgi``::
+
+  LoadModule wsgi_module modules/mod_wsgi.so
+
+Then a possible (straightforward, with e.g. no virtual server) configuration is
+as follow::
+
+  WSGIScriptAlias / /home/thu/repos/server/trunk/openerp-wsgi.py
+  WSGIDaemonProcess oe user=thu group=users processes=2 python-path=/home/thu/repos/server/trunk/ display-name=apache-openerp
+  WSGIProcessGroup oe
+
+  <Directory /home/thu/repos/server/trunk>
+      Order allow,deny
+      Allow from all
+  </Directory>
+
+The ``WSGIScriptAlias`` directive indicates that any URL matching ``/`` will
+run the application defined in the ``openerp-wsgi.py`` script.
+
+The ``WSGIDaemonProcess`` and ``WSGIProcessGroup`` directives create a process
+configuration. The configuration makes it possible for isntance to specify
+which user runs the OpenERP process. The ``display-name`` option will make the
+processes appear as ``apache-openerp`` in ``ps`` (instead of the normal
+``httpd``).
+
+Finally, it is necessary to make sure the source directory where the script can
+be found is allowed by Apache with the ``Directory`` block.
+
+``mod_wsgi`` supports a lot of directives, please see this ``mod_wsgi`` wiki
+page for more details:
+http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives.
+
+Running
+-------
+
+When the Apache configuration changes, it is necessary to restart Apache, e.g. with::
+
+  /etc/init.d/httpd restart

doc/form-view-guidelines.rst

@@ -0,0 +1,303 @@
+.. _form-view-guidelines:
+
+Form Views Guidelines
+=====================
+
+Authors: Aline Preillon, Raphael Collet
+
+
+This document presents functional and technical guidelines for
+creating/organizing form views in OpenERP version 7.0.  For each item, both the
+functional and technical aspects are explained.  The goal of the new style of
+forms is to make OpenERP easier to use, and to guide users through the system.
+
+Business Views
+--------------
+
+Business views are targeted at regular users, not advanced users.  Examples
+are: Opportunities, Products, Partners, Tasks, Projects, etc.
+
+.. image:: /form-view-guidelines/oppreadonly.png
+
+In general, a business view is composed of
+
+1. a status bar on top (with technical or business flow),
+2. a sheet in the middle (the form itself),
+3. a bottom part with History and Comments.
+
+Technically, the new form views are structured as follows in XML::
+
+    <form version=”7.0”>
+        <header> ... content of the status bar  ... </header>
+        <sheet>  ... content of the sheet       ... </sheet>
+        <div class=”oe_chatter”> ... content of the bottom part ... </div>
+    </form>
+
+The Status Bar
+''''''''''''''
+
+The purpose of the status bar is to show the status of the record and the
+action buttons, which were formerly at the bottom of form views.
+
+.. image:: /form-view-guidelines/status.png
+
+The Buttons
+...........
+
+The order of buttons follows the business flow.  For instance, in a sale order,
+the logical steps are:
+
+1. Send the quotation
+2. Confirm the quotation
+3. Create the final invoice
+4. Send the goods
+
+Highlighted buttons (in red) emphasize the logical next step, to help the user.
+It is usually the first active button.  On the other end, cancel buttons must
+remain grey (normal).  For instance, in Invoice, the button “Refund” must never
+be red.
+
+Technically, buttons are highlighted by adding the class “oe_highlight”::
+
+    <button class=”oe_highlight” name=”...” type=”...” states=”...”/>
+
+The Status
+..........
+
+We use the widget “statusbar”, and the current value of the state is shown in
+red.  One should make visible the states that are common to all flows (for
+instance, a sale order begins as a quotation, then we send it, then it becomes
+a full sale order, and finally it is done.)  Exceptions or states depending on
+particular flow are only visible if it is the current one.
+
+.. image:: /form-view-guidelines/status1.png
+
+.. image:: /form-view-guidelines/status2.png
+
+The states are shown following the order used in the field (the list in a
+selection field, etc).  States that are always visible are indicated by the
+attribute statusbar_visible.  One can also show some states in a specific color
+with statusbar_colors.
+
+::
+
+    <field name="state" widget="statusbar"
+        statusbar_visible="draft,sent,progress,invoiced,done"
+        statusbar_colors="{‘shipping_except’:’red’,’waiting_date’:’blue’}"/>
+
+The Sheet
+'''''''''
+
+All business views should look like a printed sheet:
+
+.. image:: /form-view-guidelines/sheet.png
+
+Technically, the layout of forms version 7.0 is different than former versions.
+There is no longer a default “grid” layout; instead the layout is more based on
+HTML and CSS.  The following conventions are now used:
+
+1. The elements <form> and <page> no longer define groups; the elements inside
+   are laid out inline.  One should use explicit <div> or <group> to create
+   blocks.
+2. By default, the element <group> now defines two columns inside, unless an
+   attribute col=”n” is used.  The columns have the same width (1/n th of the
+   group’s width).  Use a <group> element to produce a column of fields.
+3. The element <separator string=”XXX”/> on top of a group can be replaced
+   putting string=”XXX” inside the <group> element.
+4. The element <field name=”XXX”/> does not produce a label, except when they
+   are directly below a <group> element.  Use <label for=”XXX”/> to produce
+   the label of the field.
+
+Sheet Headers
+.............
+
+Some sheets have headers with one or more fields, and the labels of those
+fields are only shown in edit mode.
+
++---------------------------------------------+----------------------------------------------+
+|            View mode                        |                  Edit mode                   |
++---------------------------------------------+----------------------------------------------+
+| .. image:: /form-view-guidelines/header.png | .. image:: /form-view-guidelines/header2.png |
++---------------------------------------------+----------------------------------------------+
+
+Use HTML text, <div>, <h1>, <h2>… to produce nice headers, and <label> with the
+CSS class “oe_edit_only” to produce the field’s label in edit mode.  Use the
+CSS class “oe_inline” to produce inline fields (not blocks). The form above is
+produced by the following XML.
+
+::
+
+    <label for="name" class="oe_edit_only"/>
+    <h1><field name="name"/></h1>
+
+    <label for="planned_revenue" class="oe_edit_only"/>
+    <h2>
+        <field name="planned_revenue" class="oe_inline"/>
+        <field name="company_currency" class="oe_inline oe_edit_only"/> at 
+        <field name="probability" class="oe_inline"/> % success rate
+    </h2>
+
+Button Box
+..........
+
+Many relevant actions or links can be directly displayed in the form.  For
+example, in Opportunity form, the actions “Schedule a Call” and “Schedule a
+Meeting” take an important place in the use of the CRM.  Instead of placing
+them in the “More” menu of the sidebar, put them directly in the sheet as
+buttons (on the top right).
+
+.. image:: /form-view-guidelines/header3.png
+
+Technically, the buttons are placed inside a <div> to group them as a block on
+the right-hand side of the sheet.
+
+::
+
+    <div class="oe_button_box oe_right">
+        <button string="Schedule/Log Call" name="..." type="action"/>
+        <button string="Schedule Meeting" name="action_makeMeeting" type="object"/>
+    </div>
+
+Groups and Titles
+.................
+
+A column of fields is now produced with a <group> element, with an optional
+title.  The title has the same effect as placing an explicit <separator>
+element inside the group.
+
+.. image:: /form-view-guidelines/screenshot-03.png
+
+::
+
+    <group string="Payment Options">
+        <field name="writeoff_amount"/>
+        <field name="payment_option"/>
+    </group>
+
+It is recommended to have two columns of fields on the form.  For this, simply
+put the <group> elements that contain the fields inside a <group> element.
+
+To ease view inheritance, it is recommended to put a name=”...” in <group>
+elements.  Adding fields inside such a group is trivial.
+
+Special Case: Subtotals
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Some CSS classes are defined to render subtotals like in invoice forms:
+
+.. image:: /form-view-guidelines/screenshot-00.png
+
+::
+
+    <group class="oe_subtotal_footer">
+        <field name="amount_untaxed"/>
+        <field name="amount_tax"/>
+        <field name="amount_total" class="oe_subtotal_footer_separator"/>
+        <field name="residual" style="margin-top: 10px"/>
+    </group>
+
+Placeholders and Inline Fields
+..............................
+
+Sometimes field labels make the form too complex.  One can omit field labels,
+and instead put a placeholder inside the field.  The placeholder text is
+visible only when the field is empty.  The placeholder should tell what to
+place inside the field, and not be an example.
+
+One can also group fields together by rendering them “inline” inside an
+explicit block element like <div>.  This allows to group several elements in
+place of a field (without its label).
+
+The following example, taken from the Leads form, shows both placeholders and
+inline fields (zip and city).
+
++--------------------------------------------------+----------------------------------------------------+
+|                 Edit mode                        |                    View mode                       |
++--------------------------------------------------+----------------------------------------------------+
+| .. image:: /form-view-guidelines/placeholder.png | .. image:: /form-view-guidelines/screenshot-01.png |
++--------------------------------------------------+----------------------------------------------------+
+
+::
+
+    <group>
+        <label for="street" string="Address"/>
+        <div>
+            <field name="street" placeholder="Street..."/>
+            <field name="street2"/>
+            <div>
+                <field name="zip" class="oe_inline" placeholder="ZIP"/>
+                <field name="city" class="oe_inline" placeholder="City"/>
+            </div>
+            <field name="state_id" placeholder="State"/>
+            <field name="country_id" placeholder="Country"/>
+        </div>
+    </group>
+
+Images
+......
+
+Images, like avatars, should be displayed on the right of the sheet.  The
+product form looks like:
+
+.. image:: /form-view-guidelines/screenshot-02.png
+
+The form above contains a <sheet> element that starts with::
+
+    <field name="product_image" widget="image" class="oe_avatar oe_right"/>
+
+Tags
+....
+
+Many2many fields, like categories, are better rendered as a list of tags.  Use
+the widget “many2many_tags”:
+
+.. image:: /form-view-guidelines/screenshot-04.png
+
+::
+
+    <field name="category_id"
+        widget="many2many_tags"/>
+
+Configuration Forms and Wizards
+-------------------------------
+
+Configuration Forms
+'''''''''''''''''''
+
+Examples of configuration forms: Stages, Leave Type, etc.  This concerns all
+menu items under Configuration of each application (like Sales/Configuration).
+
+.. image:: /form-view-guidelines/nosheet.png
+
+For those views, the guidelines are:
+
+1. no header (because no state, no workflow, no button)
+2. no sheet
+
+Regular Wizards (Popup)
+'''''''''''''''''''''''
+
+Example: “Schedule a Call” from an opportunity.
+
+.. image:: /form-view-guidelines/wizard-popup.png
+
+The guidelines are:
+
+1. avoid separators (the title is already in the popup title bar, so another
+   separator is not relevant);
+2. avoid cancel buttons (user generally close the popup window to get the same
+   effect);
+3. action buttons must be highlighted (red);
+4. when there is a text area, use a placeholder instead of a label or a
+   separator;
+5. like in regular form views, put buttons in the <header> element.
+
+Configuration Wizard
+''''''''''''''''''''
+
+Example: Settings / Configuration / Sales.  The guidelines are:
+
+1. always in line (no popup);
+2. no sheet;
+3. keep the cancel button (users cannot close the window);
+4. the button “Apply” must be red.

doc/index.rst

@@ -17,6 +17,8 @@ OpenERP Server
    05_test_framework
    06_misc
    deployment-gunicorn
+   deployment-mod-wsgi
+   form-view-guidelines
 
 OpenERP Command
 '''''''''''''''
@@ -34,7 +36,17 @@ OpenERP Server API
 .. toctree::
    :maxdepth: 1
 
+   orm-methods.rst
    api_models.rst
+   routing.rst
+
+Changelog
+'''''''''
+
+.. toctree::
+   :maxdepth: 1
+
+   changelog.rst
 
 Concepts
 ''''''''

doc/orm-methods.rst

@@ -0,0 +1,61 @@
+.. _orm-methods:
+
+ORM methods
+===========
+
+.. _orm-workflows:
+
+Workflow-related methods
+------------------------
+
+.. versionadded:: 7.1
+
+Creating, deleting, or otherwise manipulating workflow instances is possible
+right from a Model instance. (Previously, workflows were handled throught a
+call to ``LocalService('workflow')``. Using the ORM methods is now the preferred
+way.)
+
+.. currentmodule:: openerp.osv.orm
+
+.. automethod:: BaseModel.create_workflow
+  :noindex:
+
+  This is used instead of ``LocalService('workflow').trg_create()``.
+
+.. automethod:: BaseModel.delete_workflow
+  :noindex:
+
+  This is used instead of ``LocalService('workflow').trg_delete()``.
+
+.. automethod:: BaseModel.step_workflow
+  :noindex:
+
+  This is used instead of ``LocalService('workflow').trg_write()``.
+
+.. automethod:: BaseModel.redirect_workflow
+  :noindex:
+
+.. automethod:: BaseModel.signal_workflow
+  :noindex:
+
+  This is used instead of ``LocalService('workflow').trg_validate()``.
+
+.. method:: BaseModel.signal_xxx(cr, uid, ids)
+  :noindex:
+
+  Sends a signal ``xxx`` to the workflow instances bound to the given record
+  IDs. (This is implemented using ``__getattr__`` so no source link is
+  rendered on the right.)
+
+  This is used instead of ``LocalService('workflow').trg_validate()``.
+
+
+.. note::
+  Low-level access to the workflows is still possible by using the
+  ``openerp.workflow`` module, that is, in a similar way to what was possible
+  with the previous ``LocalService('workflow')`` access. This may be useful
+  when looking-up a model in the registry and/or its records is not necessary.
+  For instance when working with raw model names and record IDs is preferred (to
+  avoid hitting unnecessarily the database). But this is something that should be
+  carefully considered as it would bypass the ORM methods (and thus any inherited
+  behaviors).

doc/report-declaration.rst

@@ -0,0 +1,23 @@
+.. _report-declaration:
+
+Report declaration
+==================
+
+.. versionadded:: 7.1
+
+Before version 7.1, report declaration could be done in two different ways:
+either via a ``<report>`` tag in XML, or via such a tag and a class
+instanciation in a Python module. Instanciating a class in a Python module was
+necessary when a custom parser was used.
+
+In version 7.1, the recommended way to register a report is to use only the
+``<report>`` XML tag. The tag can now support an additional ``parser``
+attribute. The value for that attibute must be a fully-qualified class name,
+without the leading ``openerp.addons.`` namespace.
+
+.. note::
+  The rational to deprecate the manual class instanciation is to make all
+  reports visible in the database, have a unique way to declare reports
+  instead of two, and remove the need to maintain a registry of reports in
+  memory.
+

doc/routing.rst

@@ -0,0 +1,29 @@
+.. _routing:
+
+Routing
+=======
+
+.. versionchanged:: 7.1
+
+The OpenERP framework, as an HTTP server, serves a few hard-coded URLs
+(``models``, ``db``, ...) to expose RPC endpoints. When running the web addons
+(which is almost always the case), it also serves URLs without them being RPC
+endpoints.
+
+In older version of OpenERP, adding RPC endpoints was done by subclassing the
+``openerp.netsvc.ExportService`` class. Adding WSGI handlers was done by
+registering them with the :py:func:`openerp.wsgi.register_wsgi_handler`
+function.
+
+Starting with OpenERP 7.1, exposing a new arbitrary WSGI handler is done with
+the :py:func:`openerp.http.handler` decorator while adding an RPC endpoint is
+done with the :py:func:`openerp.http.rpc` decorator.
+
+.. _routing-decorators:
+
+Routing decorators
+------------------
+
+.. automodule:: openerp.http
+   :members:
+   :undoc-members:

install/openerp-server.1

@@ -80,17 +80,6 @@ specify the certificate file for the SSL connection
 \fB\-\-pkey\-file\fR=\fISECURE_PKEY_FILE\fR
 specify the private key file for the SSL connection
 .IP
-NET\-RPC Configuration:
-.TP
-\fB\-\-netrpc\-interface\fR=\fINETRPC_INTERFACE\fR
-specify the TCP IP address for the NETRPC protocol
-.TP
-\fB\-\-netrpc\-port\fR=\fINETRPC_PORT\fR
-specify the TCP port for the NETRPC protocol
-.TP
-\fB\-\-no\-netrpc\fR
-disable the NETRPC protocol
-.IP
 Static HTTP service:
 .TP
 \fB\-\-static\-http\-enable\fR

openerp/.apidoc

@@ -1 +0,0 @@
-excludes: pychart release openerp-server test run_tests addons/base_quality_interrogation

openerp/PKG-INFO

@@ -13,6 +13,6 @@ Description: OpenERP is a complete ERP and CRM. The main features are accounting
         and financial), stock management, sales and purchases management, tasks
         automation, marketing campaigns, help desk, POS, etc. Technical features include
         a distributed server, flexible workflows, an object database, a dynamic GUI,
-        customizable reports, and NET-RPC and XML-RPC interfaces.
+        customizable reports, and an XML-RPC interface.
 Keywords: ERP, Accounting, Stock, CRM, Enterprise, Logistics, Management, Sales, Purchases
 Platform: Linux, Win32

openerp/__init__.py

@@ -1,6 +1,6 @@
 # -*- coding: utf-8 -*-
 ##############################################################################
-#    
+#
 #    OpenERP, Open Source Management Solution
 #    Copyright (C) 2004-2009 Tiny SPRL (<http://tiny.be>).
 #
@@ -15,19 +15,31 @@
 #    GNU Affero General Public License for more details.
 #
 #    You should have received a copy of the GNU Affero General Public License
-#    along with this program.  If not, see <http://www.gnu.org/licenses/>.     
+#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
 #
 ##############################################################################
 
 """ OpenERP core library.
 
 """
+
+# Make sure the OpenERP server runs in UTC. This is especially necessary
+# under Windows as under Linux it seems the real import of time is
+# sufficiently deferred so that setting the TZ environment variable
+# in openerp.cli.server was working.
+import os
+os.environ['TZ'] = 'UTC' # Set the timezone...
+import time              # ... *then* import time.
+del os
+del time
+
 # The hard-coded super-user id (a.k.a. administrator, or root user).
 SUPERUSER_ID = 1
 
 import addons
 import cli
 import conf
+import http
 import loglevels
 import modules
 import netsvc
@@ -35,10 +47,8 @@ import osv
 import pooler
 import release
 import report
-import run_tests
 import service
 import sql_db
-import test
 import tools
 import workflow
 # backward compatilbility
@@ -54,5 +64,12 @@ multi_process = False
 # Is the server running with gevent.
 evented = False
 
+def registry(database_name):
+    """
+    Return the model registry for the given database. If the registry does not
+    exist yet, it is created on the fly.
+    """
+    return modules.registry.RegistryManager.get(database_name)
+
 # vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4: