Wed, 03 May 2017 21:58:48 +0200 [massive store] ensure the cwmassive_initialized table is deleted if needed 3.25
David Douard <david.douard@logilab.fr> [Wed, 03 May 2017 21:58:48 +0200] rev 12195
[massive store] ensure the cwmassive_initialized table is deleted if needed This may be necessary if a previous import did badly crached, leaving the cwmassive_initialized behind.
Wed, 03 May 2017 21:55:41 +0200 [server] fix deserialize_schema to handle properly pg schema (closes 17076486) 3.25
David Douard <david.douard@logilab.fr> [Wed, 03 May 2017 21:55:41 +0200] rev 12194
[server] fix deserialize_schema to handle properly pg schema (closes 17076486) Postgres behaviour is to look first for a table in the configured schema then fall back to 'public' if no table is found. This must be implemented in deserialize_schema when listing existing tables to check for computed relations (cw_cwcomputedrtype) otherwise computed relations may not work when using non-default pg schema.
Wed, 10 May 2017 15:07:18 +0200 [server/utils] update passlib API to 1.7 (closes #17054805) 3.25
David Douard <david.douard@logilab.fr> [Wed, 10 May 2017 15:07:18 +0200] rev 12193
[server/utils] update passlib API to 1.7 (closes #17054805) while keeping bw-compat with 1.6 - 2.7 is not available for all distributions, e.g. jessie. The dependancy has been bumped in 6186cd15a46d because of a change in bc9d901cb9e6. We may easily use the appropriate method depending on the version installed.
Mon, 10 Jul 2017 11:43:18 +0200 Merge with 3.25 branch
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 10 Jul 2017 11:43:18 +0200] rev 12192
Merge with 3.25 branch
Mon, 10 Jul 2017 11:41:20 +0200 Added tag 3.25.1, debian/3.25.1-1, centos/3.25.1-1 for changeset 5fe62978801a 3.25
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 10 Jul 2017 11:41:20 +0200] rev 12191
Added tag 3.25.1, debian/3.25.1-1, centos/3.25.1-1 for changeset 5fe62978801a
Mon, 10 Jul 2017 11:23:45 +0200 [pkg] Version 3.25.1 3.25 3.25.1 centos/3.25.1-1 debian/3.25.1-1
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 10 Jul 2017 11:23:45 +0200] rev 12190
[pkg] Version 3.25.1
Fri, 21 Apr 2017 14:01:46 +0200 [facets] Fix disappearance of navtop component on facet filtering
Sylvain Thénault <sylvain.thenault@logilab.fr> [Fri, 21 Apr 2017 14:01:46 +0200] rev 12189
[facets] Fix disappearance of navtop component on facet filtering which is because facets are replacing the whole #pageContent div, while this one contains other stuff than the view: * a type selector component that should be dropped for a while, * a computed title, * the page navigation. Then the view content itself is in a #contentmain div. The thing is that the navigation should be rebuilded on filtering (this is not the case for other bullets in the list above). This is currently handled specifically in the ajaxcontroller (except for the type selector which will disappear... who said it should be dropped at once?). So to fix this we: * put the page navigation into the "contentmain" div * don't replace anymore "pageContent" but "contentmain" After that we can even remove from the ajax controller the code that reimplements title handling similarly to the main template. Notice the part that changes the main template has to be ported to squareui. Closes #17074195
Mon, 19 Jun 2017 18:15:28 +0200 [web] Set response status to 400 when appropriate in ajax controller
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 19 Jun 2017 18:15:28 +0200] rev 12188
[web] Set response status to 400 when appropriate in ajax controller When this is clearly a client error, set status to 400. Otherwise, keep the default value for RemoteCallFailed (status=500).
Mon, 19 Jun 2017 18:00:26 +0200 [web] Only log exceptions in debug mode in Ajax controllers
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 19 Jun 2017 18:00:26 +0200] rev 12187
[web] Only log exceptions in debug mode in Ajax controllers When we raise a RemoteCallFailed error (erroneously turned into a '500 Internal Server Error' response, but that's another business). In production environment, we do not want to log the exception in most cases where it's actually a client error. So only log the exception in debug mode.
Tue, 06 Jun 2017 12:20:17 +0200 [pyramid] Only expose 'cubicweb.bwcompat' setting for "all-in-one" configuration type 3.25
Denis Laxalde <denis.laxalde@logilab.fr> [Tue, 06 Jun 2017 12:20:17 +0200] rev 12186
[pyramid] Only expose 'cubicweb.bwcompat' setting for "all-in-one" configuration type The "pyramid" instance configuration does not work with "cubiwceb.bwcompat" mode (on purpose). Yet, having the setting exposed in development.ini file (generate by `cubicweb-ctl create --config pyramid <cube> <instance>` command) is misleading and we want to remove it. Thus, we only query this setting when cubicweb configuration is "all-in-one" and drop the setting line from templated development.ini file. If the option is found and True for any other configuration type, we issue a user warning (and ignore the option).
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 tip