Now all classes and members are either exposed to bindings or marked
as "not available in Python bindings" in the docs.
Drop test thresholds to 0. Now it should be much easier to determine
what missing members have been added which are causing test
failures.
This adds the possibility to manage data on a normalized relational
database in N:M relations. On the relation editor in a form, the tools
to add, delete, link and unlink work (also) on the linking table if a
relation is visualized as N:M relation.
Configuration is done through the fields tab where on the relation a
second relation can be chosen (if there is a suitable relation in terms
of a second relation on the linking table).
Limitations
===========
QGIS is not a database management system.
It is based on assumptions about the underlying database system. In
particular it expects
* A `ON DELETE CASCADE` or similar measure on the second relation
* Does not take care of setting the primary key when adding features.
Either users need to be instructed to set them manually or - if it's a
database derived value - the layers need to be in transaction mode
(currently only activatable through the API)
This check tests that if a function has been declared deprecated
with either Q_DECL_DEPRECATED or has a @deprecated Doxygen note
then it MUST have both the Q_DECL_DEPRECATD and @deprecated note.
It's important that both are used, as Q_DECL_DEPRECATED allows
throwing a warning if that method is used in code, while the
@deprecated doxygen note gives an indication to devs/PyQGIS users
of why it's deprecated and what should be used instead.
Ideally we'd also test for SIP /Deprecated/ tags, but I can't
find any reliable way to do this.
* make sip coverage test aware that there are less classes where QSci sip
headers are not available
* exclude properties from members
* fix QgsFeatureIds typedef (fixes missing signal
QgsVectorLayer.featuresDeleted and others)
* add missing notes for PyNames
* include some missing new methods in bindings
This introduces two new options to filter legend elements:
- filter by expression: a boolean expression can be set. Only symbols of
features that make the expression evaluated to true will be kept in the legend
- filter by polygon: only symbols of features that are inside the given
polygon will be part of the legend.
The polygon filtering is used in particular for a new option in the
composer legend that allows to filter out anything that is not included
in the current atlas polygon.
Not perfect, but good for a quick warning if a new class or member
has been added to the public API without Python bindings. The test
only considers the name of members, since it seems to be impossible
to test for the signature of a Python member. (So adding a new
overloaded method without bindings will still unfortunately pass).
You can avoid the test where bindings are not applicable:
- for a whole class by placing "@note not available in Python bindings"
in the class' Doxygen comments
- or by placing the @note inside a member's Doxygen comments for a
specific member
Additionally, classes which aren't included in the API docs
will not be tested.
