1. 30 Oct, 2017 9 commits
  2. 15 Sep, 2017 1 commit
  3. 12 Sep, 2017 1 commit
  4. 06 Oct, 2017 1 commit
    • Sylvain Thénault's avatar
      [test] Pin some test dependencies · cfd25da225c2
      Sylvain Thénault authored
      We currently have CI failures because cubes used as test dependencies have been
      updated to new-style cube layout. To avoid this, pin them to previous released.
      Those dependencies should be removed but in the mean time this should be enough
      (and backported in all active branches).
  5. 12 Sep, 2017 2 commits
  6. 11 Sep, 2017 1 commit
  7. 10 Jul, 2017 3 commits
  8. 22 Jun, 2017 1 commit
  9. 06 Jun, 2017 1 commit
    • Denis Laxalde's avatar
      [pyramid] Only expose 'cubicweb.bwcompat' setting for "all-in-one" configuration type · 36f1c7ab9010
      Denis Laxalde authored
      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).
      branch : 3.25
  10. 27 Apr, 2017 1 commit
  11. 05 May, 2017 1 commit
  12. 21 Apr, 2017 1 commit
    • Sylvain Thénault's avatar
      [facets] Fix disappearance of navtop component on facet filtering · ef46695adb68
      Sylvain Thénault authored
      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
  13. 19 Jun, 2017 2 commits
  14. 28 Apr, 2017 1 commit
    • Philippe Pepiot's avatar
      [req] fix find() generating non-rewritable rql on non final relations · af5d0a3c3f1a
      Philippe Pepiot authored
      When filtering on a relation, find() was generating rql like
      'Any X WHERE X is ETYPE, X relation EID' which work without being rewritten (it
      should probably not), but when applying some rewrite (eg. permissions) it raise
      in rqlrewrite code.
      	def _use_orig_term(self, snippet_varname, term):
      	>       self.rewritten[key] = term.name
      	E       AttributeError: 'Constant' object has no attribute 'name'
      Generate valid rql instead 'Any X WHERE X is ETYPE, X relation Y, Y eid EID'.
  15. 26 Apr, 2017 1 commit
  16. 25 Apr, 2017 3 commits
  17. 21 Apr, 2017 2 commits
  18. 25 Apr, 2017 1 commit
  19. 20 Apr, 2017 1 commit
  20. 21 Apr, 2017 1 commit
    • Sylvain Thénault's avatar
      [rqlrewrite] Fix rewrite on ambiguities introduced by NOT relation or "is IN" type restriction · 02b8325720d6
      Sylvain Thénault authored
      When some inserted RQL snippet generate more solutions than the original RQL,
      the rewriter attempt to duplicate the snippet for each newly introduced
      solution. There are though some cases where we do not want this behaviour in
      case of ambiguities introduced by:
      * NOT(X relation Y) expression, since it won't be
        equivalent to NOT(X relation Y1, Y1 is Type1) OR NOT(X relation Y2, Y2 is
        Type2) ;
      * EXISTS(X relation Y, Y is IN (Type1, Type2) expression, since it's not
        actually necessary to split an explicitly introduced ambiguity (and it crash
        if we attempt to do so, so...).
      In test, we've to modify the `rewrite()` function because in the newly
      introduced test we need the same constraint to be applied to two variables in
      the original query, and this was not supported before.
      Notice the generated RQL in test is still *NOT CORRECT* "(EXISTS(NOT EXISTS() OR
      EXISTS(...))", or at least isn't optimal. This will be fixed in a forthcoming
      Related to #17074119
  21. 19 Apr, 2017 2 commits
  22. 20 Apr, 2017 1 commit
  23. 19 Apr, 2017 2 commits