GitLab

Basically:

mkdir cubicweb
hg mv *.py -X setup.py cubicweb
hg mv dataimport devtools entities etwist ext hooks i18n misc schemas server skeleton sobjects test web wsgi cubicweb

Other changes:

* adjust path to cubicweb-ctl in devtools tests
* update setup.py to avoid importing __pkginfo__ (exec it instead),
  replace os.path.walk by os.walk and prepend `modname` here and there
* update tox.ini to account for new test locations
* update doc/conf.py so that it still finds __pkginfo__.py and CWDIR in
  doc/Makefile

If fetch_attrs includes relations, stop including the entities on the
other side in our sorting.  Fixes regression from 73ea636a5562 where we
would sort on the target entity before the attribute we wanted if the
relation's name sorted before the attribute's.  This showed up in the
forge/tracker cubes with Version entities being sorted by their State's
name in preference to their version number.

Historically, we used a ldap://... URI as cwuri attribute, not just the
dn.  The extid field, OTOH, was always the dn.  So when initializing our
dict of known entities from an ldap source, look at existing extids, not
cwuris, to avoid importing already-existing users (and violated unicity
constraints).

Life without an eid is made of sadness.

Avoid TypeError when comparing tz-naive and tz-aware objects in fresh()
method.

If we have new computed attributes we need to set their formula_select
attribute or things get sad.

The json module expects str, not bytes, so we need to do the decoding.

- ldap3 dicts contain unicode strings
- extid must be bytes

Related to #4848923.

by depending on logilab-database 1.15.0 including
https://www.logilab.org/ticket/1485893, we can now keep the tzinfo
attribute on datetime objects for TZDatetime attributes, so one knows
that this is a tz-aware datetime.

To easily make it work with backends that have no tz support, we keep
converting tz-aware datetime objects into utc naive datetime objects
before sending them to the database.

No work has been done for form fields/widgets since creation_date /
modification_date are by default not editable through the default UI. One may
want to add such feature at some point.

Time will be displayed as UTC, let the end-application decide otherwise by
customizing the tzdatetime printer if desired.

Closes #4848923

NB: at this point, the TZ info is completely ignored.  It will be
properly handled in later commits.

The patch prevents problems due to a SQLite bug causing some values to
be returned as strings instead of properly typed objects.

This should probably be improved to use SQLite connection hooks.  But
the major improvement is that the monkeypatch is now done all the time,
and not just for tests.

with other (sqlite) test databases. Closes #9240765

Simplify .hgignore in passing.

I changed it to a class attribute recently, but on further thought (and
prompting from Adrien) it seems to make more sense as an instance
attribute.

It couldn't work as-is because entities_id_seq is not a sequence object.

Instead provide a utility function to reset the eid sequence.

The metadata insertion is to be done only by the master-mode store.

Ideally we'd use "pg_dump --schema-only" to compare before/after, but when
restoring a constraint such as:

  cstr48f9ceae537d68859b62c601681c8d3e CHECK (((cw_type)::text = ANY ((ARRAY['normal'::character varying, 'auto'::character varying])::text[])))

postgres will convert the text cast on array to a cast on each cell of array

  cstr48f9ceae537d68859b62c601681c8d3e CHECK (cw_type::text = ANY (ARRAY['normal'::character varying::text, 'auto'::character varying::text]))

It is now done in __init__.

We want to be able to restore constraints at the end of the import.  If
they are silently dropped due to a CASCADE, we can't do that.

This should avoid dependency issues when dropping specific constraints (e.g.
when dropping a primary constraint referenced by a foreign key constraint).

We only do this in master mode, slave mode stores are supposed to work
with an initialized db already.

Primary keys show up in both lists of constraints and indexes.  Pick a
side and stick to it.

While cleaning up the use of init_config() in WSGIAppTC, I wondered why
the method was trying to set the 'https_uiprops' and 'https_datadir_url'
attributes on the config, when WebConfiguration's __init__ should be
taking care of setting them.

WSGIAppTC uses the default configuration - one that derives from
ApptestConfiguration (noted as G below).

The issue is that the class hierarchy of ApptestConfiguration includes
TestServerConfiguration (C in the graph below) which calls
ServerConfiguration's __init__ directly (B below). As B does not have an
__init__ method, CubicWebConfiguration's __init__ is called directly (A
below). This has the unintended consequence of preventing
WebConfiguration's __init__ from being called.


   A
  / \
 B   D
 |   |
 C   E
  \ /
   F
   |
   G
   |
  ...

A: cwconfig.CubicWebConfiguration

B: server.serverconfig.ServerConfiguration
C: devtools.TestServerConfiguration

D: web.webconfig.WebConfiguration
E: etwist.twconfig.WebConfigurationBase

F: devtools.BaseApptestConfiguration
G: devtools.ApptestConfiguration

NB: unittest_wsgi wasn't really broken, as it's the only test in
wsgi/test/, but I figured I might as well clean it up.

Related to #9297611.

To reproduce (with a purged repo):

* python web/test/test_jscript.py
* python web/test/unittest_views_xmlrss.py

The '__default_empty_db__' will contain the wrong 'base_url'
configuration, thus breaking URLs in the xmlrss tests.

Closes #9297611.

To reproduce (with a purged repo):

* python web/test/unittest_web.py MiscOptionsTC
* python web/test/unittest_views_xmlrss.py

The core issue is that CubicWebServerConfig.default_base_url() is called
inside init_config(), which is called during the equivalent of
'db-create'. The '__default_empty_db__' will contain the wrong
'base_url' configuration, thus breaking URLs in the xmlrss tests.

Related to #9297611.