Openerp压力测试:Openerp到底能支撑多大的用户数?

OpenERP(以下简称为OE) 是一个开源ERP/CRM系统,使用Python语言开发,数据库采用开源的PostgreSQL,系统以GNU GPL开 源协议发布。在过去人们的印象中,OE一般是用在中小企业居多。除了业务上、功能上等因素外,技术上的因素也是需要考虑,OE能否顶住大流量、高并发的各 种操作呢?本文对OE进行了一系列的压力测试,当然测试方法可能比较单一和片面,所得出的测试结果也是仅供各位看官参考。

1.  测试环境

1.1  硬件环境

  • DELL 1420 笔记本
  • CPU:Intel(R) Core(TM)2 Duo CPU     T5450  @ 1.66GHz
  • 内存:1G
  • 硬盘:160G

1.2  软件环境

  • 操作系统:Debian Linux  2.6.39-2-686-pae #1 SMP Tue Jul 5 03:48:49 UTC 2011 i686 GNU/Linux
  • OpenERP Server版本:openerp-server-6.0.2
  • OpenERP web client:openerp-web-6.0.2
  • CherryPY 版本:3.1.2

1.3  相关参数设置

  • OE Server:启动方式为 ./openerp-server.py -c openerp-server.conf ,conf 配置文件是从deb 包解压出来的,没有做任何修改。
    安装了一个test帐套,默认安装了测试数据,语言选取为英文。启用了CRM、SALES、WAREHOUSE、INVOCING、ACCOUNTING、PURCHASE 模块。
  • OE Web:启动方式为 ./openerp-web.py ,默认加载的配置文件为 ./doc/openerp-web.cfg ,修改第二行为 server.environment = “production”,其他保持默认。(默认值为server.environment = “development”时,会加载_TimeoutMonitor 和 Autoreloader,会降低部分性能。)
  • CherryPY: 在cherrypy/_cpserver.py文件中有两个重要参数,分别是46行的socket_queue_size = 5 和 51行thread_pool = 10 ,这里修改为socket_queue_size = 500 和 thread_pool = 1000。(这两个参数如果在保持默认值的情况下,连并发100都跑不了。不明白CherryPY的默认值为什么这么低 …)

注:oe server 和 oe web client 都直接下载源码运行,未使用deb安装版。

1.4  测试方法

采用ab (ApacheBench) 工具,分别进行10、100、1000并发,总数1000的任务,对OE web client 进行访问,也就是http://127.0.0.1:8080 。分别测试首页和内页(内页访问是需要登录的,因此内页测试结果应该更接近实际使用情况)。

应当指出的是,这里只测试通过web 客户端并发方式,未使用GTK客户端的方式测试。通过GTK客户端方式访问,是直接访问OE Server ,少了OE Web Client 这层的转化,理论上应该比web 客户端方式效率更高。

2.  测试过程

由于篇幅的原因,下面没有贴出完整的测试输出,只贴了关键部分。如需完整的测试结果,请下载本文附件。

2.1  测试首页

关于首页地址,首页地址不能使用http://127.0.0.1:8080,因为访问http://127.0.0.1:8080时,OE Web Client 会返回一个http 303转向,因此只能使用 http://127.0.0.1:8080/openerp/login?db=&user=

2.1.1  10并发测试 (点击下载测试结果文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ ab -n 1000 -c 10  'http://127.0.0.1:8080/openerp/login?db=&user='

Document Path:          /openerp/login?db=&user=
Document Length:        11383 bytes

Concurrency Level:      10
Time taken for tests:   11.493 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      11638000 bytes
HTML transferred:       11383000 bytes
Requests per second:    87.01 [#/sec] (mean)
Time per request:       114.925 [ms] (mean)
Time per request:       11.493 [ms] (mean, across all concurrent requests)
Transfer rate:          988.92 [Kbytes/sec] received

2.1.2  100并发测试(点击下载测试结果文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ ab -n 1000 -c 100  'http://127.0.0.1:8080/openerp/login?db=&user='

Document Path:          /openerp/login?db=&user=
Document Length:        11383 bytes

Concurrency Level:      100
Time taken for tests:   10.237 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      11638000 bytes
HTML transferred:       11383000 bytes
Requests per second:    97.68 [#/sec] (mean)
Time per request:       1023.700 [ms] (mean)
Time per request:       10.237 [ms] (mean, across all concurrent requests)
Transfer rate:          1110.21 [Kbytes/sec] received

2.1.3  1000并发测试(点击下载测试结果文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ ab -n 1000 -c 1000  'http://127.0.0.1:8080/openerp/login?db=&user='

Document Path:          /openerp/login?db=&user=
Document Length:        11383 bytes

Concurrency Level:      1000
Time taken for tests:   12.416 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      11638000 bytes
HTML transferred:       11383000 bytes
Requests per second:    80.54 [#/sec] (mean)
Time per request:       12416.356 [ms] (mean)
Time per request:       12.416 [ms] (mean, across all concurrent requests)
Transfer rate:          915.34 [Kbytes/sec] received

从上面的结果来看,性能相当不错啊,呵呵。在并发1000的情况下,平均每个请求耗时12.416毫秒!通过分别察看10并发、100并发、1000并发的测试结果,可以看到处理时间并不一定随着并发数的增长而线性增长。

不过,ab 测试并不代表真实的情况,ab 工具只取了http 的 header 部分,只要是返回200就认为是成功的。而实际的浏览器请求中,还需要处理图片、JS、CSS等文件。另外,首页是不需要登录的,而实际使用当中,大部分 都是需要登录的操作,因此下面的测试就通过访问一个菜单来模拟用户登录后的情况。

2.2  测试需要登录的内页

这里使用的URL地址是 http://127.0.0.1:8080/openerp/menu?active=73 ,正常情况下是需要登录的。ab 工具提供了一个 -C 选项,可以设置cookie。通过设置cookie ,我们就可以模拟登录情况。

使用Firefox 访问http://127.0.0.1:8080并登录后,打开首选项->隐私->显示cookie,找到127.0.0.1,可以看到OE 设置的cookie值,这里只要使用session_id就可以了。ab 的示例用法为:

1
$ ab -n 1000 -c 10 -C session_id=577291be968298c229eb887a618f881018e9b7a8 'http://127.0.0.1:8080/openerp/menu?active=73'

2.2.1  10并发测试(点击下载测试结果文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ ab -n 1000 -c 10 -C session_id=b9df27fa455e06954ea3f08cade4ac911e0f688e 'http://127.0.0.1:8080/openerp/menu?active=73'

Document Path:          /openerp/menu?active=73
Document Length:        127271 bytes

Concurrency Level:      10
Time taken for tests:   242.542 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      127527000 bytes
HTML transferred:       127271000 bytes
Requests per second:    4.12 [#/sec] (mean)
Time per request:       2425.418 [ms] (mean)
Time per request:       242.542 [ms] (mean, across all concurrent requests)
Transfer rate:          513.47 [Kbytes/sec] received

2.2.2  100并发测试(点击下载测试结果文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ ab -n 1000 -c 100 -C session_id=b9df27fa455e06954ea3f08cade4ac911e0f688e 'http://127.0.0.1:8080/openerp/menu?active=73'

Document Path:          /openerp/menu?active=73
Document Length:        127271 bytes

Concurrency Level:      100
Time taken for tests:   243.160 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      127527000 bytes
HTML transferred:       127271000 bytes
Requests per second:    4.11 [#/sec] (mean)
Time per request:       24315.977 [ms] (mean)
Time per request:       243.160 [ms] (mean, across all concurrent requests)
Transfer rate:          512.17 [Kbytes/sec] received

2.2.3  1000并发测试(点击下载测试结果文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ ab -n 1000 -c 1000 -C session_id=b9df27fa455e06954ea3f08cade4ac911e0f688e 'http://127.0.0.1:8080/openerp/menu?active=73'

Document Path:          /openerp/menu?active=73
Document Length:        127271 bytes

Concurrency Level:      1000
Time taken for tests:   243.017 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      127527000 bytes
HTML transferred:       127271000 bytes
Requests per second:    4.11 [#/sec] (mean)
Time per request:       243017.391 [ms] (mean)
Time per request:       243.017 [ms] (mean, across all concurrent requests)
Transfer rate:          512.47 [Kbytes/sec] received

从上面的结果来看,1000并发平均每个请求耗时243.017毫秒!。与首页测试12.416毫秒相比,差不多有19.57倍的差距。不过这也很正常, 访问上面的菜单需要加载许多模块。分别观察10并发、100并发、1000并发的测试结果来看,处理时间的差距并不明显。

2.3  NET-RPC or XML-RPC ?

NET-RPC是OE支持的一个接口,察看源代码可以看到其实现机制是比较简单的,主要是通cPickle 模块将对象序列化,然后通过TCP Socket传输,接收后反序列化的一个过程。XML-RPC是工作在Internet上的远程过程调用协议,一个XML-RPC消息就是一个请求体为xml的http-post请求,被调用的方法在服务器端执行并将执行结果以xml格式编码后返回。

从原理上来说NET-RPC的速度要比XML-RPC快,官方也是推荐使用NET-RPC。那么到底快多少呢?请看下面的测试结果。

测试之前,需要修改./doc/openerp-web.cfg 配置文件,把52行修改为 openerp.server.protocol = ‘http’ 表示使用XML-RPC协议(原默认值是 socket,表示使用NET-RPC协议),还有 openerp.server.port 改为 8069(默认值是 8070)。

2.3.1  XML-RPC 100 并发测试(点击下载测试结果文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ ab -n 1000 -c 100 -C session_id=349f6eb43a5fb2b9227cd63f56ae666096f7381b 'http://127.0.0.1:8080/openerp/menu?active=73'

Document Path:          /openerp/menu?active=73
Document Length:        127271 bytes

Concurrency Level:      100
Time taken for tests:   369.974 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      127527000 bytes
HTML transferred:       127271000 bytes
Requests per second:    2.70 [#/sec] (mean)
Time per request:       36997.414 [ms] (mean)
Time per request:       369.974 [ms] (mean, across all concurrent requests)
Transfer rate:          336.61 [Kbytes/sec] received

平均每请求耗时369.974毫秒,而上面使用NET-RPC100并发是243.160毫秒,是使用NETRPC的1.52倍。

3.  结论

通过以上的测试过程,我个人认为OE完全可以支持1000+的并发需求,满足企业的日常使用以及以后增长需求。尤其是在我这个老爷笔记本的硬件下,相信现在很多PC硬件已经几倍甚至几十倍超越我的笔记本了。

建议一:如果使用OE Web Client,建议调整CherryPY的socket_queue_size 和 thread_pool 参数,以提高CherryPY的并发支持能力,避免Web 副服务器成为应用瓶颈。

建议二:如果不是一定要使用XML-RPC的情况下,尽量使用NET-RPC协议。

 

http://www.360yun.info/blog/512796206.html

Posted in Uncategorized | Leave a comment

Openerp压力测试:多线程直连OE Server NET-RPC/XML-RPC端口测试

Openerp压力测试:多线程直连OE Server NET-RPC/XML-RPC端口测试

2011-08-12 17:22

分类:

之前发表的一篇文章 Openerp压力测试:Openerp到底能支撑多大的用户数? ,转贴到OpenERP中文社区和OpenERP QQ群(69195329)之后,得到了许多童靴的关注,尤其是很多前辈的鼓励和转贴。这里就不一一道谢了。总之,谢谢大家!

也有善意的质疑,某童靴就指出,“不代表 OE server 的 xmlrpc 性能的.  中间或者有 cherrypy 的缓存在起作用.  并发100 已经相当牛X了.”,某童靴同时也提出,“期待 清沙出个 xmlrpc/netrpc 直接性能测试版本….射射….”。我表示,完全没有鸭梨。

今天偷得半日浮生,想起某童靴的教导,不由的觉得一种鸭梨油然而生,!^@!*A**&* 今天天气晴朗,万里乌云,小朋友们高高兴兴的。。。(原谅我吧,一有鸭梨,总是想起当年有个可怜的小朋友在憋课堂作文的时候)。废话少说,今天写了一小段 Python代码,用于测试OpenERP NET-XML 和 XML-RPC性能。本人才疏学浅,代码中如有臭虫或错误之处,还望各位童靴斧正。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
#! /usr/bin/python#! /usr/bin/python
# -*- coding: utf-8 -*-
#
# OE压力测试小工具  www.360yun.info
#

# 导入 openerprpc 模块。
# 纯属个人习惯,如果您是使用apt或者python setup.py 等方式安装的话,
# 可以无视下面2行
import sys,os
sys.path.append (os.path.abspath(os.path.join(os.path.dirname(__file__), 'openerprpc-1.0.1')))
import openerprpc

import threading
import Queue
import datetime
import time

#参数设置
JOBS_COUNT = 1000 #任务总数
THREAD_LIMIT = 100 #并发线程数
HOST = '127.0.0.1' #主机IP
PROTOCOL = 'netrpc' #可选值 netrpc xmlrpc
PORT = 'auto' #端口
DATABASE = 'test' #数据库
LOGIN = 'admin' #用户名
PASSWORD = 'admin' #密码
USER_ID = None #用户id

#队列
jobs = Queue.Queue(0)
def thread(num):
    while True:
        try:
            job = jobs.get(False)
        except Queue.Empty:
            return

        #连接OE Server
        conn = openerprpc.get_connection(HOST, protocol=PROTOCOL, port=PORT,
                                        database=DATABASE, login=LOGIN,
                                        password=PASSWORD, user_id=USER_ID)
        #取第一个partner 记录
        company = conn.get_object('res.partner').read([(1)],[('name')])
        print 'job %s thread %s : %s ' % (str(job) , str(num), str(company))
        time.sleep(1/1000) # 休息1毫秒


def main():
    #将任务压入队列
    for job in range(JOBS_COUNT):
        jobs.put(job)

    start_time = datetime.datetime.now()

    #启动线程
    for n in range(THREAD_LIMIT):
        t = threading.Thread(target = thread, kwargs = {'num': n})
        t.start()

    #等待线程结束
    while threading.activeCount() > 1:
        pass

    end_time = datetime.datetime.now()

    print '\r\nStart at %s' % str(start_time)
    print 'End   at %s' % str(end_time)
    print '\r\nTotal Time: %s' % str(end_time - start_time)

if __name__ == "__main__":
    main()

上面的程序使用官方的openerprpc模块连接到OE Server,支持NET-RPC和XML-RPC连接方式,使用很简单,例子请看上面的代码。下载地址是http://pypi.python.org/pypi/openerprpc 。下载之后用 python setup.py 安装。当然,也可以不安装,代码中用sys.path.append添加openerprpc的路径即可,如同上面的代码。

OpenERP中文社区论坛里面也介绍了其他如oersted 等,不过下载来看了下只支持NET-RPC。GOOGLE之后发现原来官方也有出rpc客户端模块,缺点就是官方的openerprpc模块没有文档也没 有样例。呵呵,有机会在来写写openerprpc模块介绍。

按照上面的程序代码,就可以运行了么?当然可以运行,如果你没有改动我的程序的话,很快你就会得到以下错误:

1
error: [Errno 104] Connection reset by peer

神马?不会吧,这明显是Socket Server 撑不住啊。难道连100并发都搞不定?难道某童靴一语言中?莫慌,打开OE的源码来看看(这就是开源的好处啊,哇哈哈)……中间省略数万字….  下面是解决办法:

1、编辑 openerp-server-6.0.2/bin/service/netrpc_server.py ,找到以下代码(112行):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class TinySocketServerThread(threading.Thread,netsvc.Server):
    def __init__(self, interface, port, secure=False):
        threading.Thread.__init__(self, name="NetRPCDaemon-%d"%port)
        netsvc.Server.__init__(self)
        self.__port = port
        self.__interface = interface
        self.socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        self.socket.bind((self.__interface, self.__port))
        #self.socket.listen(5)
        #此处修改为128 或更大 这个是Socket 队列,不是监听端口,详情请Google之。
        self.socket.listen(128)
        self.threads = []
        netsvc.Logger().notifyChannel("web-services", netsvc.LOG_INFO, 
                         "starting NET-RPC service at %s port %d" % (interface or '0.0.0.0', port,))

2、编辑 openerp-server-6.0.2/bin/service/http_server.py ,找到以下代码(80 行):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
class ThreadedHTTPServer(ConnThreadingMixIn, SimpleXMLRPCDispatcher, HTTPServer):

    encoding = None
    allow_none = False
    allow_reuse_address = 1
    _send_traceback_header = False
    i = 0

    def __init__(self, addr, requestHandler, proto='http',
                 logRequests=True, allow_none=False, encoding=None, bind_and_activate=True):
        self.logRequests = logRequests

        SimpleXMLRPCDispatcher.__init__(self, allow_none, encoding)
        HTTPServer.__init__(self, addr, requestHandler)

        self.numThreads = 0
        self.proto = proto
        self.__threadno = 0

        #此处添加一行
        self.socket.listen(128)

        # [Bug #1222790] If possible, set close-on-exec flag; if a
        # method spawns a subprocess, the subprocess shouldn't have
        # the listening socket open.
        if fcntl is not None and hasattr(fcntl, 'FD_CLOEXEC'):
            flags = fcntl.fcntl(self.fileno(), fcntl.F_GETFD)
            flags |= fcntl.FD_CLOEXEC
            fcntl.fcntl(self.fileno(), fcntl.F_SETFD, flags)

3、编辑OE Server 的配置文件openerp-server.conf,在最后添加以下代码:

1
2
; 数据库连接池数量
db_maxconn = 128

这个是数据库的连接池数量,出处请察看源码openerp-server-6.0.2/bin/sql_db.py 第258行处,默认值是64。如果你启动OE没有使用配置文件,那么你只好修改源码了。sql_db.py 的代码节选如下:(使用配置文件的话,此处无须修改,只是举例说明db_maxconn这个参数不是凭空得来)

1
2
3
4
5
6
7
8
class ConnectionPool(object):
#################中间省略无数代码######################
    def __init__(self, maxconn=64):
        self._connections = []
        self._maxconn = max(maxconn, 1)
        self._lock = threading.Lock()
#################中间省略无数代码######################
_Pool = ConnectionPool(int(tools.config['db_maxconn']))

经过三个参数的修改,我们的测试程序终于可以正常运行了。但,程序很有可能输出异常,虽然程序可以运行。异常情况如下:

1
UnpicklingError: Global and instance pickles are not supported.

尤其是第一次启动测试程序,再次启动,就没事了。貌似线程占用资源问题,不知道是不是要加个线程锁。百思不得其解啊,求各位高手给个说法。

测试结果

1、NET-RPC 100并发 1000总任务

1
2
3
4
Start at 2011-08-12 20:16:45.058085
End   at 2011-08-12 20:16:52.233411

Total Time: 0:00:07.175326

2、XML-RPC 100并发 1000总任务 (运行这个测试请把测试代码中参数修改为 PROTOCOL = ‘xmlrpc’ #可选值 netrpc xmlrpc)

1
2
3
4
Start at 2011-08-12 20:20:21.405651
End   at 2011-08-12 20:20:32.149523

Total Time: 0:00:10.743872

从上面的测试结果看,XML-RPC所花时间是NET-RPC时间的  1.497335731 倍。与我上一篇OE测试结果相近。

结论

1、 某童靴,你赢了!”不代表 OE server 的 xmlrpc 性能的.  中间或者有 cherrypy 的缓存在起作用“,您的观点是正确的。OE Web Client 在通过RPC获取对象之后,会把对象缓存在OE Web Client 自己的 cache中。官方文档 http://doc.openerp.com/v6.0/book/1/1_1_Inst_Config/1_1_Inst_Config_architecture.html 中也提到这点。

When you are changing the structure of your OpenERP installation (adding and
removing modules, perhaps changing labels), you might find the web client to be
irritating because of its use of caching.

2、如果在部署OE应用是,如果需要高并发,建议调整OE Server 中netrpc_server 和 http_server 的 socket.listen,数据库连接池 db_maxconn也建议你调整到更高。在默认情况下,OE Server 的确不能支持100并发或更多。(如果你也同时使用OE Web Client,请参照之前发表的一篇文章 Openerp压力测试:Openerp到底能支撑多大的用户数? 进行调整)

3、开放源代码的力量是无穷的,本文调整参数的例子就很好的说明一切。假如你部署的ERP系统,随着业务量的增长遇上性能瓶颈是,估计大部分商业公司给你的建议都是升级到更高、更新的版本,或是购买更强的硬件服务器。没有开放源代码,你甚至都不知道哪儿出问题。

后记

突然发现,我这篇文章简直就是洋洋洒洒、又长又硬啊。。。画外音:写作文,从来都没有这么容易,我的秘诀是——多贴代码(和声)!!!

最后的最后(画外音:还有?欠扁啊?!),附上打包的源代码(猛点这里下载),已包含openerprpc-1.0.1,无须安装,直接运行 oetest.py 即可。。。谢谢大家,最后,我简单讲几句。。。

 

http://www.360yun.info/blog/910961413.html

Posted in Uncategorized | Leave a comment

Generating Open ERP docs: the beauty of sphinx

http://toolpart.hu/blog/2011/07/22/generating-open-erp-docs-beauty-sphinx/

At ToolPart Team we always try to document as much of our code as possible. Documentation is present everywhere in our work:

  • we write specifications to our clients
  • we write comments in our code
  • we write yaml test that work as documentation too
  • the description field of our Open ERP addons serve the purpose of documentation
  • etc

Unfortunately, our favourite ERP framework still lacks documentation. As we dive into it more and more, we always found undocumented parts. That last one was its workflow service. So, after understanding it, we documented it.

We decided to document the workflow service using docstring, and to use Sphinx’ autodoc module to add the documentation into the Developers book.

Building the docs is described in the Open ERP Community book. But it wasn’t that easy! We had already a system-wide sphinx installation, while openerp is installed in a virtualenv. Even if we installed sphinx under the virtualenv, it could not import the openerp modules. What goes wrong? We had no idea, but finally figured out.

It’s not enough to have openerp-server, as a Pyton package under your sys.path’s directory. We had to add the openerp-server directory directly using the PYTHONPATH environment variable. This is mentioned in the docs already, but it wasn’t totally clear.

Thus running

PYTHONPATH=~/.virtualenvs/openerp6/lib/python2.6/site-packages/openerp-servermakehtml

Now builds the docs properly.

Posted in Uncategorized | Leave a comment

Training modules moved to new project and team

Training modules moved to new project and team

First versions of training OpenERP modules were developed by OpenERP S.A. and AJM Technologies S.A. An “special” version of the openerp-server was required for run this first version of training modules, so they could not be installed in an standard OpenERP server v5 or v6.
For this reason, Zikzakmedia created a training fork project some months ago. We have cleaned code to work with version 5 of openerp-server. Later, we migrated these modules to version 6 openerp-server.
This code was available in addons-extra of v5 and v6 respectively. We started only migrating 3 modules and now there are available 16 news modules (multishchool, dining-hall, e-learning app, …). Also, in this time we have cleaned, fixed and added new features in training base modules.
Now, we think that a new community project is necessary.
  1. Independent community project: Better visibility, everyone can access to project.
  2. Any-person interested in training management could have permissions to publish (only few members can publish code at addons-extra).
  3. Easily publication of code in a branch for testing new features, fixing, …
  4. One project for training modules to join efforts. Not a lot of branches scattered in different projects.
  5. Having their own translations, blueprints, bugs, …
More information:
Posted in Uncategorized | Leave a comment

查找某条记录的id

根据老肖的pdf教程,导入数据的时候可以指定这一条数据的 id,便于以后导入相关表时 ref 它。在模块开发的时候也有很多时候需要知道menu 或 view的id。以前一直是到原模块的xml文件中去找,效率很低。群里也有很多人问起,今天终于找到了。 数据库里有个表ir_model_data对应的对象ir.model.data就是用来存储这些字符类型的id的。 name就是我们要的字符型的 id model是这条记录所属的对象名 res_id是这条记录在它的model所在的数据表里的database id,也就是那个唯一的主键 那么去哪里得到当前记录的model和res_id呢? 哈哈,地址栏 这么有用的表,每次都到数据库里去sql就太笨了吧,好在我们可以给 对象ir.model.data建个菜单,再自定义视图把model和res_id设置为 总是可搜索。 效果如下:

Posted in Uncategorized | Leave a comment

如何实现有条件的显示记录

http://shine-it.net/index.php/topic,2214.msg7100.html#msg7099

Posted in Uncategorized | Leave a comment

OpenERP Training e-learning. On-line training

Training e-learning is OpenERP module and APP for Django. Add new features training modules for SEO and use web application for your students training, without connectors.

In this demo, you can view OpenERP offers available for this student (subscription), courses doc (wiki), questionnaires and questions for exams (there are 4 type question: plain text, QCM, QCU and Yes/No).

Student are available all content information about courses and available make a test and auto-validation.

http://zikzakmedia.blogspot.com/2011/06/openerp-training-e-learning-on-line.html

Posted in Uncategorized | Leave a comment