OpenERP Web Core and standard addons¶
- General organization and core ideas (design philosophies)
- Internal documentation, autodoc, Python and JS domains
- QWeb code documentation/description
- Documentation of the OpenERP APIs and choices taken based on that?
- Style guide and coding conventions (PEP8? More)
- Test frameworks in JS?
Standard Views¶
Search View¶
The OpenERP search view really is a sub-view, used in support of views acting on collections of records (list view or graph view, for instance).
Its main goal is to collect information from its widgets (themselves collecting information from the users) and make those available to the rest of the client.
The search view’s root is SearchView()
. This
object should never need to be created or managed directly, its
lifecycle should be driven by the
ViewManager()
.
The search view defines a number of internal and external protocols to communicate with the objects around and within it. Most of these protocols are informal, and types available for inheritance are more mixins than mandatory.
Events¶
on_loaded
Fires when the search view receives its view data (the result of
fields_view_get
). Hooking up before the event allows for altering view data before it can be used.By the time
on_loaded
is done, the search view is guaranteed to be fully set up and ready to use.
on_search
Event triggered after a user asked for a search. The search view fires this event after collecting all input data (contexts, domains and group_by contexts). Note that the search view does not merge those (or otherwise evaluate them), they are returned as provided by the various inputs within the view.
on_clear
Triggered after a user asked for a form clearing.
Input management¶
An important concept in the search view is that of input. It is both an informal protocol and an abstract type that can be inherited from.
Inputs are widgets which can contain user data (a char widget for instance, or a selection box). They are capable of action and of reaction:
registration
This is an input action. Inputs have to register themselves to the main view (which they receive as a constructor argument). This is performed by pushing themselves on theopenerp.base.SearchView.inputs
array.
get_context
An input reaction. When it needs to collect contexts, the view calls
get_context()
on all its inputs.Inputs can react in the following manners:
Return a context (an object), this is the “normal” response if the input holds a value.
Return a value that evaluates as false (generally
null
). This value indicates the input does not contain any value and will not affect the results of the search.Raise
openerp.base.search.Invalid()
to indicate that it holds a value but this value can not be used in the search (because it is incorrectly formatted or nonsensical). RaisingInvalid()
is guaranteed to cancel the search process.
Invalid()
takes three mandatory arguments: an identifier (a name for instance), the invalid value, and a validation message indicating the issue.
get_domain
The second input reaction, the possible behaviors of inputs are the same as forget_context
.
The openerp.base.search.Input()
type implements registration
on its own, but its implementations of get_context
and
get_domain
simply raise errors and must be overridden.
One last action is for filters, as an activation order has to be kept on them for some controls (to establish the correct grouping sequence, for instance).
To that end, filters can call
openerp.base.Search.do_toggle_filter()
, providing themselves
as first argument.
Filters calling do_toggle_filter()
also
need to implement a method called
is_enabled()
, which the search
view will use to know the current status of the filter.
The search view automatically triggers a search after calls to
do_toggle_filter()
.
Life cycle¶
The search view has a pretty simple and linear life cycle, in three main steps:
init()
Nothing interesting happens here
start()
Called by the main view’s creator, this is the main initialization step for the list view.
It begins with a remote call to fetch the view’s descriptors (
fields_view_get
).Once the remote call is complete, the
on_loaded
even happens, holding three main operations:
make_widgets()
Builds and returns the top-level widgets of the search view. Because it returns an array of widget lines (a 2-dimensional matrix of widgets) it should be called recursively by container widgets (openerp.base.search.Group()
for instance).
render()
Called by the search view on all top-level widgets. Container widgets should recursively call this method on their own children widgets.
Widgets are provided with a mapping of
{name: value}
holding default values for the search view. They can freely pick their initial values from there, but must pass the mapping to their children widgets if they have any.
start()
The last operation of the search view startup is to initialize all its widgets in order. This is again done recursively (the search view starts its children, which have to start their own children).
stop()
Used before discarding a search view, allows the search view to disable its events and pass the message to its own widgets, gracefully shutting down the whole view.
Widgets¶
In a search view, the widget is simply a unit of display.
All widgets must be able to react to three events, which will be called in this order:
render()
Called with a map of default values. The widget must return a
String
, which is its HTML representation. That string can be empty (if the widget should not be represented).Widgets are responsible for asking their children for rendering, and for passing along the default values.
start()
Called without arguments. At this point, the widget has been fully rendered and can set its events up, if any.
The widget is responsible for starting its children, if it has any.
stop()
Gives the widget the opportunity to unbind its events, remove itself from the DOM and perform any other cleanup task it may have.
Even if the widget does not do anything itself, it is responsible for shutting down its children.
An abstract type is available and can be inherited from, to simplify the implementation of those tasks:
Inputs¶
The search namespace (openerp.base.search
) provides two more
abstract types, used to implement input widgets:
openerp.base.search.Input()
is the most basic input type, it only implements input registration.If inherited from, descendant classes should not call its implementations of
get_context()
andget_domain()
.openerp.base.search.Field()
is used to implement more “field” widgets (which allow the user to input potentially complex values).It provides various services for its subclasses:
Sets up the field attributes, using attributes from the field and the view node.
It fills the widget with
Filter()
if the field has any child filter.It automatically generates an identifier based on the field type and the field name, using
make_id()
.It sets up a basic (overridable)
template
attribute, combined with the previous tasks, this makes subclasses ofField()
render themselves “for free”.It provides basic implementations of
get_context
andget_domain
, both hinging on the subclasses implementingget_value()
(which should return a correct, converted Javascript value):get_context()
Checks if the field has a non-
null
and non-empty (String
) value, and that the field has acontext
attr.If both conditions are fullfilled, returns the context.
get_domain()
Only requires that the field has a non-
null
and non-empty value.If the field has a
filter_domain
, returns it immediately. Otherwise, builds a context using the field’s name, the fieldoperator
and the field value, and returns it.
List View¶
OpenERP Web’s list views don’t actually exist as such in OpenERP itself: a
list view is an OpenERP tree view in the view_mode
form.
The overall purpose of a list view is to display collections of objects in two main forms: per-object, where each object is a row in and of itself, and grouped, where multiple objects are represented with a single row providing an aggregated view of all grouped objects.
These two forms can be mixed within a single list view, if needed.
The root of a list view is openerp.base.ListView()
, which may need
to be overridden (partially or fully) to control list behavior in non-view
cases (when using a list view as sub-component of a form widget for instance).
Creation and Initialization¶
As with most OpenERP Web views, the list view’s
init()
takes quite a number of arguments.
While most of them are the standard view constructor arguments
(view_manager
, session
, element_id
, dataset
and an
optional view_id
), the list view adds a number of options for basic
customization (without having to override methods or templates):
selectable
(default:true
)- Indicates that the list view should allow records to be selected individually. Displays selection check boxes to the left of all record rows, and allows for the triggering of the selection event.
deletable
(default:true
)- Indicates that the list view should allow records to be removed individually. Displays a deletion button to the right of all record rows, and allows for the triggering of the deletion event.
header
(default:true
)- Indicates that list columns should bear a header sporting their name (for non-action columns).
addable
(default:"New"
)- Indicates that a record addition/creation button should be displayed in the list’s header, along with its label. Also allows for the triggering of the record addition event.
sortable
(default:true
)- Indicates that the list view can be sorted per-column (by clicking on its column headers).
reorderable
(default:true
)- Indicates that the list view records can be reordered (and re-sequenced) by drag and drop.
Events¶
Addition¶
The addition event is used to add a record to an existing list view. The default behavior is to switch to the form view, on a new record.
Addition behavior can be overridden by replacing the
do_add_record()
method.
Selection¶
The selection event is triggered when a given record is selected in the list view.
It can be overridden by replacing the
do_select()
method.
The default behavior is simply to hide or display the list-wise deletion button depending on whether there are selected records or not.
Deletion¶
The deletion event is triggered when the user tries to remove 1..n records from the list view, either individually or globally (via the header button).
Deletion can be overridden by replacing the
do_delete()
method. By default, this method
calls unlink()
in order to remove the records
entirely.
Note
the list-wise deletion button (next to the record addition button)
simply proxies to do_delete()
after
obtaining all selected record ids, but it is possible to override it
alone by replacing
do_delete_selected()
.
Internal API Doc¶
Python¶
These classes should be moved to other sections of the doc as needed, probably.
See also: OpenERPSession
,
OpenERPModel
-
class
web.common.http.
Root
(options, openerp_addons_namespace=True)¶ Root WSGI application for the OpenERP Web Client.
Parameters: options – mandatory initialization options object, must provide the following attributes:
server_host
(str
)- hostname of the OpenERP server to dispatch RPC to
server_port
(int
)- RPC port of the OpenERP server
serve_static
(bool | None
)- whether this application should serve the various addons’s static files
storage_path
(str
)- filesystem path where HTTP session data will be stored
dbfilter
(str
)- only used in case the list of databases is requested by the server, will be filtered by this pattern
-
dispatch
(environ, start_response)¶ Performs the actual WSGI dispatching for the application, may be wrapped during the initialization of the object.
Call the object directly.
-
find_handler
(*l)¶ Tries to discover the controller handling the request for the path specified by the provided parameters
Parameters: l – path sections to a controller or controller method Returns: a callable matching the path sections, or None
Return type: Controller | None
-
web.common.http.
jsonrequest
(f)¶ Decorator marking the decorated method as being a handler for a JSON-RPC request (the exact request path is specified via the
$(Controller._cp_path)/$methodname
combination.If the method is called, it will be provided with a
JsonRequest
instance and allparams
sent during the JSON-RPC request, apart from thesession_id
,context
anddebug
keys (which are stripped out beforehand)
-
web.common.http.
httprequest
(f)¶ Decorator marking the decorated method as being a handler for a normal HTTP request (the exact request path is specified via the
$(Controller._cp_path)/$methodname
combination.If the method is called, it will be provided with a
HttpRequest
instance and allparams
sent during the request (GET
andPOST
merged in the same dictionary), apart from thesession_id
,context
anddebug
keys (which are stripped out beforehand)
-
class
web.common.http.
Controller
¶
-
class
web.common.http.
WebRequest
(request, config)¶ Parent class for all OpenERP Web request types, mostly deals with initialization and setup of the request object (the dispatching itself has to be handled by the subclasses)
Parameters: - request (
werkzeug.wrappers.BaseRequest
) – a wrapped werkzeug Request object - config – configuration object
-
httprequest
¶ the original
werkzeug.wrappers.Request
object provided to the request
-
httpsession
¶ a
Mapping
holding the HTTP session data for the current http session
-
config
¶ config parameter provided to the request object
-
params
¶ Mapping
of request parameters, not generally useful as they’re provided directly to the handler method as keyword arguments
-
session_id
¶ opaque identifier for the
session.OpenERPSession
instance of the current request
-
session
¶ OpenERPSession
instance for the current request
-
context
¶ Mapping
of context values for the current request
-
debug
¶ bool
, indicates whether the debug mode is active on the client
-
init
(params)¶
- request (
-
class
web.common.http.
JsonRequest
(request, config)¶ JSON-RPC2 over HTTP.
Sucessful request:
--> {"jsonrpc": "2.0", "method": "call", "params": {"session_id": "SID", "context": {}, "arg1": "val1" }, "id": null} <-- {"jsonrpc": "2.0", "result": { "res1": "val1" }, "id": null}
Request producing a error:
--> {"jsonrpc": "2.0", "method": "call", "params": {"session_id": "SID", "context": {}, "arg1": "val1" }, "id": null} <-- {"jsonrpc": "2.0", "error": {"code": 1, "message": "End user error message.", "data": {"code": "codestring", "debug": "traceback" } }, "id": null}
-
dispatch
(controller, method)¶ Calls the method asked for by the JSON-RPC2 or JSONP request
Parameters: - controller – the instance of the controller which received the request
- method – the method which received the request
Returns: an utf8 encoded JSON-RPC2 or JSONP reply
-
-
class
web.common.http.
HttpRequest
(request, config)¶ Regular GET/POST request
-
dispatch
(controller, method)¶
-
make_response
(data, headers=None, cookies=None)¶ Helper for non-HTML responses, or HTML responses with custom response headers or cookies.
While handlers can just return the HTML markup of a page they want to send as a string if non-HTML data is returned they need to create a complete response object, or the returned data will not be correctly interpreted by the clients.
Parameters: - data (basestring) – response body
- headers (
[(name, value)]
) – HTTP headers to set on the response - cookies (collections.Mapping) – cookies to set on the client
-
not_found
(description=None)¶ Helper for 404 response, return its result from the method
-
-
class
web.controllers.main.
Action
¶ -
action_mapping
= {'ir.actions.act_url': 'ir.actions.url'}¶
-
load
(controller, request, config)¶
-
run
(controller, request, config)¶
-
-
class
web.controllers.main.
Binary
¶ -
content_disposition
(filename, req)¶
-
image
(controller, request, config)¶
-
placeholder
(req)¶
-
saveas
(controller, request, config)¶ Download link for files stored as binary fields.
If the
id
parameter is omitted, fetches the default value for the binary field (viadefault_get
), otherwise fetches the field for that precise record.Parameters: - req (
web.common.http.HttpRequest
) – OpenERP request - model (str) – name of the model to fetch the binary from
- field (str) – binary field
- id (str) – id of the record from which to fetch the binary
- filename_field (str) – field holding the file’s name, if any
Returns: werkzeug.wrappers.Response
- req (
-
saveas_ajax
(controller, request, config)¶
-
upload
(controller, request, config)¶
-
upload_attachment
(controller, request, config)¶
-
-
class
web.controllers.main.
CSVExport
¶ -
content_type
¶
-
filename
(base)¶
-
fmt
= {'tag': 'csv', 'label': 'CSV'}¶
-
from_data
(fields, rows)¶
-
-
class
web.controllers.main.
DataSet
¶ -
call
(controller, request, config)¶
-
call_common
(req, model, method, args, domain_id=None, context_id=None)¶
-
call_kw
(controller, request, config)¶
-
create
(controller, request, config)¶
-
default_get
(controller, request, config)¶
-
do_get
(req, model, ids, fields=False)¶ Fetches and returns the records of the model
model
whose ids are inids
.The results are in the same order as the inputs, but elements may be missing (if there is no record left for the id)
Parameters: - req (openerpweb.JsonRequest) – the JSON-RPC2 request object
- model (str) – the model to read from
- ids (list) – a list of identifiers
- fields (list | False) – a list of fields to fetch,
False
or empty to fetch all fields in the model
Returns: a list of records, in the same order as the list of ids
Return type: list
-
do_search_read
(req, model, fields=False, offset=0, limit=False, domain=None, sort=None)¶ Performs a search() followed by a read() (if needed) using the provided search criteria
Parameters: - req (openerpweb.JsonRequest) – a JSON-RPC request object
- model (str) – the name of the model to search on
- fields ([str]) – a list of the fields to return in the result records
- offset (int) – from which index should the results start being returned
- limit (int) – the maximum number of records to return
- domain (list) – the search domain for the query
- sort (list) – sorting directives
Returns: A structure (dict) with two keys: ids (all the ids matching the (domain, context) pair) and records (paginated records matching fields selection set)
Return type: list
-
exec_workflow
(controller, request, config)¶
-
fields
(controller, request, config)¶
-
get
(controller, request, config)¶
-
load
(controller, request, config)¶
-
name_search
(controller, request, config)¶
-
onchange
(controller, request, config)¶ Support method for handling onchange calls: behaves much like call with the following differences:
- Does not take a domain_id
- Is aware of the return value’s structure, and will parse the domains if needed in order to return either parsed literal domains (in JSON) or non-literal domain instances, allowing those domains to be used from JS
Parameters: - req (web.common.http.JsonRequest) –
- model (str) – object type on which to call the method
- method (str) – name of the onchange handler method
- args (list) – arguments to call the onchange handler with
- context_id (int) – index of the context object in the list of arguments
Returns: result of the onchange call with all domains parsed
-
read
(controller, request, config)¶
-
save
(controller, request, config)¶
-
search_read
(controller, request, config)¶
-
unlink
(controller, request, config)¶
-
-
class
web.controllers.main.
Database
¶ -
backup
(controller, request, config)¶
-
change_password
(controller, request, config)¶
-
create
(controller, request, config)¶
-
drop
(controller, request, config)¶
-
get_list
(controller, request, config)¶
-
restore
(controller, request, config)¶
-
-
class
web.controllers.main.
ExcelExport
¶ -
content_type
¶
-
filename
(base)¶
-
fmt
= {'tag': 'xls', 'error': 'XLWT required', 'label': 'Excel'}¶
-
from_data
(fields, rows)¶
-
-
class
web.controllers.main.
Export
¶ -
content_type
¶ Provides the format’s content type
-
fields_get
(req, model)¶
-
fields_info
(req, model, export_fields)¶
-
filename
(base)¶ Creates a valid filename for the format (with extension) from the provided base name (exension-less)
-
formats
(controller, request, config)¶ Returns all valid export formats
Returns: for each export format, a pair of identifier and printable name Return type: [(str, str)]
-
from_data
(fields, rows)¶ Conversion method from OpenERP’s export data to whatever the current export class outputs
Params list fields: a list of fields to export Params list rows: a list of records to export Returns: Return type: bytes
-
get_fields
(controller, request, config)¶
-
graft_subfields
(req, model, prefix, prefix_string, fields)¶
-
index
(controller, request, config)¶
-
namelist
(controller, request, config)¶
-
-
class
web.controllers.main.
Import
¶ -
detect_data
(controller, request, config)¶
-
fields_get
(req, model)¶
-
import_data
(controller, request, config)¶
-
-
class
web.controllers.main.
Menu
¶ -
action
(controller, request, config)¶
-
do_get_user_roots
(req)¶ Return all root menu ids visible for the session user.
Parameters: req (< session -> OpenERPSession >) – A request object, with an OpenERP session attribute Returns: the root menu ids Return type: list(int)
-
do_load
(req)¶ Loads all menu items (all applications and their sub-menus).
Parameters: req (< session -> OpenERPSession >) – A request object, with an OpenERP session attribute Returns: the menu root Return type: dict(‘children’: menu_nodes)
-
get_user_roots
(controller, request, config)¶
-
load
(controller, request, config)¶
-
-
class
web.controllers.main.
Proxy
¶ -
load
(controller, request, config)¶ Proxies an HTTP request through a JSON request.
It is strongly recommended to not request binary files through this, as the result will be a binary data blob as well.
Parameters: - req – OpenERP request
- path – actual request path
Returns: file content
-
-
class
web.controllers.main.
Reports
¶ -
POLLING_DELAY
= 0.25¶
-
TYPES_MAPPING
= {'doc': 'application/vnd.ms-word', 'odt': 'application/vnd.oasis.opendocument.text', 'html': 'text/html', 'sxw': 'application/vnd.sun.xml.writer', 'pdf': 'application/pdf', 'xls': 'application/vnd.ms-excel'}¶
-
index
(controller, request, config)¶
-
-
class
web.controllers.main.
SearchView
¶ -
add_to_dashboard
(controller, request, config)¶
-
fields_get
(controller, request, config)¶
-
get_filters
(controller, request, config)¶
-
load
(controller, request, config)¶
-
save_filter
(controller, request, config)¶
-
-
class
web.controllers.main.
Session
¶ -
authenticate
(controller, request, config)¶
-
change_password
(controller, request, config)¶
-
check
(controller, request, config)¶
-
destroy
(controller, request, config)¶
-
eval_domain_and_context
(controller, request, config)¶ Evaluates sequences of domains and contexts, composing them into a single context, domain or group_by sequence.
Parameters: - contexts (list) – list of contexts to merge together. Contexts are evaluated in sequence, all previous contexts are part of their own evaluation context (starting at the session context).
- domains (list) – list of domains to merge together. Domains are evaluated in sequence and appended to one another (implicit AND), their evaluation domain is the result of merging all contexts.
- group_by_seq (list) – list of domains (which may be in a different
order than the
contexts
parameter), evaluated in sequence, their'group_by'
key is extracted if they have one.
Returns: a 3-dict of:
- context (
dict
) the global context created by merging all of
contexts
- domain (
list
) the concatenation of all domains
- group_by (
list
) a list of fields to group by, potentially empty (in which case no group by should be performed)
-
get_lang_list
(controller, request, config)¶
-
get_session_action
(controller, request, config)¶ Gets back a previously saved action. This method can return None if the action was saved since too much time (this case should be handled in a smart way).
Parameters: key (integer) – The key given by save_session_action() Returns: The saved action or None. Return type: anything
-
get_session_info
(controller, request, config)¶
-
modules
(controller, request, config)¶
-
save_session_action
(controller, request, config)¶ This method store an action object in the session object and returns an integer identifying that action. The method get_session_action() can be used to get back the action.
Parameters: the_action (anything) – The action to save in the session. Returns: A key identifying the saved action. Return type: integer
-
sc_list
(controller, request, config)¶
-
session_info
(req)¶
-
-
class
web.controllers.main.
View
¶ -
add_custom
(controller, request, config)¶
-
fields_view_get
(req, model, view_id, view_type, transform=True, toolbar=False, submenu=False)¶
-
load
(controller, request, config)¶
-
parse_domains_and_contexts
(elem, session)¶ Converts domains and contexts from the view into Python objects, either literals if they can be parsed by literal_eval or a special placeholder object if the domain or context refers to free variables.
Parameters: - elem – the current node being parsed
- session (openerpweb.openerpweb.OpenERPSession) – OpenERP session object, used to store and retrieve non-literal objects
-
process_toolbar
(req, toolbar)¶ The toolbar is a mapping of section_key: [action_descriptor]
We need to clean all those actions in order to ensure correct round-tripping
-
process_view
(session, fvg, context, transform, preserve_whitespaces=False)¶
-
transform_view
(view_string, session, context=None)¶
-
undo_custom
(controller, request, config)¶
-
-
class
web.controllers.main.
WebClient
¶ -
css
(controller, request, config)¶
-
csslist
(controller, request, config)¶
-
get_last_modified
(files)¶ Returns the modification time of the most recently modified file provided
Parameters: files (list(str)) – names of files to check Returns: most recent modification time amongst the fileset Return type: datetime.datetime
-
home
(controller, request, config)¶
-
js
(controller, request, config)¶
-
jslist
(controller, request, config)¶
-
login
(controller, request, config)¶
-
make_conditional
(req, response, last_modified=None, etag=None)¶ Makes the provided response conditional based upon the request, and mandates revalidation from clients
Uses Werkzeug’s own
ETagResponseMixin.make_conditional()
, after settinglast_modified
andetag
correctly on the response objectParameters: - req (web.common.http.WebRequest) – OpenERP request
- response (werkzeug.wrappers.Response) – Werkzeug response
- last_modified (datetime.datetime) – last modification date of the response content
- etag (str) – some sort of checksum of the content (deep etag)
Returns: the response object provided
Return type: werkzeug.wrappers.Response
-
manifest_glob
(req, addons, key)¶
-
manifest_list
(req, mods, extension)¶
-
qweb
(controller, request, config)¶
-
qweblist
(controller, request, config)¶
-
server_wide_modules
(req)¶
-
translations
(controller, request, config)¶
-
version_info
(controller, request, config)¶
-
-
web.controllers.main.
clean_action
(req, action, do_not_eval=False)¶
-
web.controllers.main.
concat_files
(file_list, reader=None, intersperse='')¶ Concatenates contents of all provided files
Parameters: - file_list (list(str)) – list of files to check
- reader (function) – reading procedure for each file
- intersperse (str) – string to intersperse between file contents
Returns: (concatenation_result, checksum)
Return type: (str, str)
-
web.controllers.main.
concat_xml
(file_list)¶ Concatenate xml files
Parameters: file_list (list(str)) – list of files to check Returns: (concatenation_result, checksum) Return type: (str, str)
-
web.controllers.main.
eval_context_and_domain
(session, context, domain=None)¶
-
web.controllers.main.
fix_view_modes
(action)¶ For historical reasons, OpenERP has weird dealings in relation to view_mode and the view_type attribute (on window actions):
- one of the view modes is
tree
, which stands for both list views and tree views - the choice is made by checking
view_type
, which is eitherform
for a list view ortree
for an actual tree view
This methods simply folds the view_type into view_mode by adding a new view mode
list
which is the result of thetree
view_mode in conjunction with theform
view_type.This method also adds a
page
view mode in case there is aform
in the input action.TODO: this should go into the doc, some kind of “peculiarities” section
Parameters: action (dict) – an action descriptor Returns: nothing, the action is modified in place - one of the view modes is
-
web.controllers.main.
generate_views
(action)¶ While the server generates a sequence called “views” computing dependencies between a bunch of stuff for views coming directly from the database (the
ir.actions.act_window model
), it’s also possible for e.g. buttons to return custom view dictionaries generated on the fly.In that case, there is no
views
key available on the action.Since the web client relies on
action['views']
, generate it here fromview_mode
andview_id
.Currently handles two different cases:
- no view_id, multiple view_mode
- single view_id, single view_mode
Parameters: action (dict) – action descriptor dictionary to generate a views key for
-
web.controllers.main.
load_actions_from_ir_values
(req, key, key2, models, meta)¶
-
web.controllers.main.
parse_context
(context, session)¶ Parses an arbitrary string containing a context, transforms it to either a literal context or a
common.nonliterals.Context
Parameters: - context – the context to parse, if the context is not a string it is assumed to be a literal domain and is returned as-is
- session (openerpweb.openerpweb.OpenERPSession) – Current OpenERP session
-
web.controllers.main.
parse_domain
(domain, session)¶ Parses an arbitrary string containing a domain, transforms it to either a literal domain or a
common.nonliterals.Domain
Parameters: - domain – the domain to parse, if the domain is not a string it is assumed to be a literal domain and is returned as-is
- session (openerpweb.openerpweb.OpenERPSession) – Current OpenERP session
-
web.controllers.main.
topological_sort
(modules)¶ Return a list of module names sorted so that their dependencies of the modules are listed before the module itself
modules is a dict of {module_name: dependencies}
Parameters: modules (dict) – modules to sort Returns: list(str)
Testing¶
Python¶
Testing for the OpenERP Web core is similar to testing addons: the tests live in openerpweb.tests
, unittest2
is the testing framework and tests can be run via either unittest2
(unit2 discover
) or via nose (nosetests
).
Tests for the OpenERP Web core can also be run using setup.py
test
.