Once we save dbfilter in configuration file, It is ignored

Bug #940439 reported by Sebastian J. Bronner on 2012-02-24

This bug report was converted into a question: question #192379: dbfilter in configuration file is ignored.

This bug affects 17 people
Affects Status Importance Assigned to Milestone
Fix Committed
OpenERP's Framework R&D
OpenERP Community Backports (Server)
Status tracked in 7.0

Bug Description

Version: 6.1-1-1 as packaged for ubuntu
Platform: Ubuntu Oneiric Ocelot 11.10

erp61 GA was announced yesterday. So, I eagerly installed it today, and I was delighted about the new dbfilter (using a regular expression). However, every pattern I put into the configuration file was ignored.

Thankfully, openerp is open source, so I was able to debug what was happening to my value. It was being clobbered by the default value during the check whether it had been assigned at the command line.

/usr/share/pyshared/openerp/tools/config.py line 387
"self.options[arg] = getattr(opt, arg)

The problem is in line 154. The default value is specified using "default='.*'" instead of the proper "my_default='.*'".


Related branches

Thanks for that it works great.
Now with simply dbfilter= demo* you have only demo, demo1, demo_test etc. in the list

Mikel (mikel-martin-q) wrote :

It seems from your comments that the bug is related to openobject-server project instead of openobject-addons

Nhomar - Vauxoo (nhomar) wrote :

This is not a bug is a request of information.,


Changed in openobject-addons:
importance: Undecided → Low
affects: openobject-addons → openobject-server
Changed in openobject-server:
status: New → Invalid
mikel (mikel-martin) wrote :

I've the same problem and the solutions proposed solves it. Thanks Sebastian

Florent (florent.x) wrote :

AFAIK, this is a bug: the option "dbfilter =" from the configuration file should be taken into account.

When you pass the option "-s" on the command line, this option is dumped in the sample config file, but if you change it it is not applied.
The proposed change fixes it.

Changed in openobject-server:
status: Invalid → Confirmed
Alvar Vilu (alvar-vilu) wrote :

Not quite the same but if using proxy:

    def get_list(self, req):
        proxy = req.session.proxy("db")
        dbs = proxy.list()
        h = req.httprequest.environ['HTTP_HOST'].split(':')[0]
        d = h.split('.')[0]
        r = req.config.dbfilter.replace('%h', h).replace('%d', d)
        dbs = [i for i in dbs if re.match(r, i)]
        return {"db_list": dbs}

then it will be HTTP_X_FORWARDED_HOST' that needs to be splitted and replaced against matches

Amit Parik (amit-parik) wrote :
Amit Parik (amit-parik) wrote :

Hello Folks,

I have checked this issue, and db_filter is working fine with web interface. Might be you have used this config parameter with gtk client but it's not working with gtk.

Just go though openerp server type check the help with --help, you can seen like this.

  Web interface Configuration:
    --db-filter=REGEXP Filter listed database

So It means that db filter is only used for web interface with regular expression. I have checked this with web interface and it's working fine. Would you please check attached video.

This is not a bug that's why I am closing this issue.

Thanks for understanding!

Changed in openobject-server:
status: Confirmed → Invalid
Amit Parik (amit-parik) wrote :

Hello Sebastian,

Sorry, I missed something that is I did not check with -s parameter means I missed to check this parameter with server conf file.

Once I have saved it then check this parameter is doesn't works.

That's I am confirming this issue for save option.


summary: - dbfilter in configuration file is ignored
+ Once we save dbfilter in configuration file, It is ignored
Changed in openobject-server:
status: Invalid → Confirmed
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
Amit Parik (amit-parik) wrote :


I have checked lp:~mikel-martin/openobject-server/6.1-fix-dbfilter-ignored-in-config-file branch of mikel this fix was done at 4081 rev and it's works fine.

Thanks for contribution mikel.

Changed in openobject-server:
status: Confirmed → Fix Committed
mikel (mikel-martin) wrote :

Something must have gone wrong, this bug is present again, at least in 4259

Changed in openobject-server:
status: Fix Committed → Confirmed

Bug is still there even in Trunk. Can't someone just fix it instead of just keep in ideal for so long time. It's just matter of 3 characters, isn't it ?

The Loeki (the-loeki) wrote :

Yes please.

The second bug reported here by Alvar (#6) is also easily fixed by adding:

    if 'HTTP_X_FORWARDED_HOST' in req.httprequest.environ:
        h = 'HTTP_HOST'
    h = req.httprequest.environ[h].split(':')[0]

to openerp/addons/web/controllers/main.py (lines 136+)

The Loeki (the-loeki) wrote :

I've filed a new bug for the proxy bug, as it's distinctly different from this one:

Daniel Hammerschmidt (redneck) wrote :

Again, concerning the missing dbfilter-option from the config file. It is not the matter of default or my_default. I figured out, the problem is the order of setting default value, reading config files, parsing command line and setting default or other values again in parse_config() (and __init__()).

Attached you'll find a patch on v7.0 alpha r8417 wich fixes this.

- apply hard-coded defaults to the configparser
- read config file and replace default values with the values from the config file
- parse the command line
- check validity

Furthermore, the parts of the comma separated list "addons_path" now may _begin_ with ~ROOT_PATH/ wich is replaced by the directory of the "openerp" package (usually the directory of the "openerp-server" file). (This is also done for the "addons" directory if the option is not given).

For more information see the code comments.

Shahar Or (mightyiam) on 2013-05-09
tags: added: patch
Shahar Or (mightyiam) wrote :

Seems fixed to me.

Changed in openobject-server:
status: Confirmed → Fix Committed
no longer affects: ocb-addons
no longer affects: ocb-server

Why not merge to official release, at least in trunk?

Jaka (jaka-luthar) wrote :

Unbelievable! I needed months to find this. Thanks for the solution, everybody.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Bug attachments