1. 05 Jun, 2019 1 commit
  2. 11 Jun, 2019 1 commit
    • Julien Tayon's avatar
      Fix sorting key for rdefs in schema viewer · de1c0721656e
      Julien Tayon authored
      With changeset 234ca3cbbb46, clicking in the schema of an entity with
      cubicweb in py3 on "vue en boite" will probably result in an infinite
      spinner (which implies cw > 3.26)
      What happened ?
      This "vue en boite" used to work at least until...
      hg diff -c a8c1ea390400 cubicweb/schema.py
          @@ -993,10 +992,6 @@ class CubicWebRelationSchema(PermissionM
                               return False
                   return True
          -    @deprecated('use .rdef(subjtype, objtype).role_cardinality(role)')
          -    def cardinality(self, subjtype, objtype, target):
          -        return self.rdef(subjtype, objtype).role_cardinality(target)
           class CubicWebSchema(Schema):
               """set of entities and relations schema defining the possible data sets
      But, wait ...
      If I open a shell on an instance of cw 3.24 something seems off
      >>> list(schema['CWUniqueTogetherConstraint'].relation_definitions())[0][0].cardinality
      # <bound method CubicWebRelationSchema.wrapped of <constraint_of [CWUniqueTogetherConstraint,CWEType]>>
      We have been sorting on a method the whole time ? Is it possible what
      were the effects ?
      1) We cannot sort function can't we ?
      >>> def adder(i): return lambda x: x+i
      >>> sorted(map(adder,range(10)))
      [<function __main__.<lambda>>,
       <function __main__.<lambda>>,
      Yes we can.
      2) what does it means.
      >>> { adder(1) : 1 }
      Out[19]: {<function __main__.<lambda>>: 1}
      In fact the function object as a __hash__ method (which is practical for making
      memoizers (cache)), and return truly random results (pseudo random).
      My take on this patch is relations have NEVER been sorted by cardinality.
      No one never ever noticed. Hence, I propose to not fix a bug that never was
  3. 04 Jun, 2019 2 commits
  4. 11 Jun, 2019 1 commit
  5. 07 Jun, 2019 3 commits
  6. 06 Jun, 2019 1 commit
  7. 28 May, 2019 1 commit
  8. 24 May, 2019 1 commit
  9. 23 May, 2019 3 commits
  10. 21 May, 2019 1 commit
  11. 16 May, 2019 1 commit
    • Julien Tayon's avatar
      [ldapfeed] FIX: Unique Key violation when synchronizing with LDAPfeed · 3f125fdbcd70
      Julien Tayon authored
      What was happening
      The bug appears when ldapfeed tries to insert a user while another user exists
      exists with a different source.
      Simple use case to reproduce:
      - create a local user in cubicweb (source=system)
      - sync with ldap
      - ldapfeed will stop complaining user already exists.
      Without next patch the test MUST fail with message:
      cubicweb/server/sources/native.py:714: UniqueTogetherError
      The ldapfeed is thus stopped ignoring any further ldap entries.
      The proposal
      Prior to this patch, the insertion was trying to create all CWUser with the
      computed login from eeimporter.extid2eid (method process of DataFeedLDAPAdapter).
      When a CWUser existed with a different cw_source ("system" for user created
      with cubicweb for instance), it created a conflict.
      To avoid collisions, in the extentities_generator method a bypass
      was added at the insertion layer.
      Prior to insertion the absence of the computed login is checked on a list of
      all existing login from a different source.
      If collision is detected, we skip the ldap record.
      By short circuiting at the CWUser entity insertion level we also avoid to treat
      CWGroup and EmailAddress related to this user.
      Hence ensuring a behaviour that will not break existing instances.
      (conservative approach: faced with ambiguity better do nothing than guess).
      An error message is added stating explicitly the conflict.
      branch : 3.26
  12. 28 Mar, 2019 1 commit
    • Philippe Pepiot's avatar
      [server/test] make test filename uniques · 3648a2c293f6
      Philippe Pepiot authored
      To avoid these pytest error when collecting the whole test suite:
      import file mismatch:
      imported module 'unittest_utils' has this __file__ attribute:
      which is not the same as the test file we want to collect:
      Move cubicweb/server/test/unittest_security.py to cubicweb/server/test/unittest_security.py
      and cubicweb/test/unittest_utils.py to cubicweb/test/unittest_server_utils.py
  13. 24 May, 2019 1 commit
  14. 22 May, 2019 4 commits
  15. 21 May, 2019 2 commits
  16. 16 May, 2019 8 commits
  17. 15 May, 2019 6 commits
  18. 10 May, 2019 1 commit
    • Philippe Pepiot's avatar
      Move CWSchemaTC to RQLExpressionTC · 7882ad333954
      Philippe Pepiot authored
      The test actually doesn't require a cubicweb schema, except for testing
      EmailAdress which is out of scope of the test (testing RQLExpression.transform_has_permission()).
      Just move the test in existing RQLExpressionTC inheriting from TestCase and
      rename the tests to be more explicit.
  19. 17 Apr, 2019 1 commit