Corrected: Value relation widget update incorrectly tries to use value instead of key
The mapped key has to be set in the return value (not the input value).
In the release-2_18 the key was returned correctly but in another structure. So this is corrected now.
...by moving extra arguments to new LayerOptions structs. This allows
us to more easily add new layer constructor options without making
the API cumbersome to use.
Widgets may on initialisation send out a notification that the value changed (from invalid to something sensible).
The attribute form should however only tell the rest of the world, that a value changed if the new value doesn't
correspond to the one in the cached QgsFeature.
Fix#17425
The column headers of "Referenced Field" and "Referenced Layer" were switched with respect to their content. Changed to the correct order in GUI now.
Fix#17409
Attempt to verify bug 17410 Identify tool->download in a not authorised folder block qgis
The test passes, so let's push it in, I'll continue
to investigate if there is an issue in the GUI logic.
This fixes an unreported bug that prevent imports of
private keys with wrong/unknown extension.
The old logic relied on the file extension, that is
not only weak but plain wrong because the same extension
can have different encodings.
The new implementation is 100% robust because completely
ignores the file extentions and try to load the key with
all supported encodings and algorithms before giving up.
Issue was, that the cellchange is triggered at re-sorting - so we need to check the names
Following issue was, that when removing or renaming something in re-sorted table - so there was a bug that referenced to the row instead of the index
Thought about to remove mIndexedWidgets completely, but when renumbering after delete in unsorted table, we cannot reference to the row order.
...by updating the list immediately when changes are made to the
current projection's name or definition. Previously the list
was only updated when a new item in the list was clicked, but that
made it appear as though the current changes were not applied
immediately and left users looking for a "save" button to actually
lock-in their changes.
By updating the list immediately we make it obvious that the
changes apply immediately and no further action is required (except
for hitting OK on the dialog!)
Since the copy is actually copying the definition OVER the
current crs definition (as opposed to adding a NEW custom
crs with the copied definition), it should sit next to the
definition box and not in the same space as the add crs
button.
