add configuration flags to QgsFields

[3nids]

This is a preliminary work to allow defining if fields are searchable in active layer locator filter
(feature request: #36701)

The idea to use flags is to make this future proof and easily extend the flags.
Saving/reading to XML will be handy using QMetaEnum::valueToKeys

(Later on, WMS/WFS capabilities could be moved to these flags)

[3nids]

Before going any further, I'd like to know if there is any objections to adding such flags to QgsField.

[elpaso]

@3nids I like the idea of the flags but we need to clear up the semantics: are these flags if directly related to the data source?
I tend to think at QgsField as a container for properties that come directly from the provider. So, if the "Searchable" flag comes from the provider (e.g. WMS exposing queryable) it is ok for me, but if that is a property that the user sets I have some doubts it's the right way to go.

For example, for the server flags: they are basically set by the user and are part of the layer configuration in the server context. I would keep them separate, but I like the flags approach though.

[3nids]

but if that is a property that the user sets I have some doubts it's the right way to go.

yes, it's intended to be set by the user.

I would keep them separate

So you would add a new list as a property of the layer?

I like the idea of moving this to field because the information is where you need it, you already have iterators for the fields.
It avoids having to keep the lists in sync with possible changing fields in the layer (adding/removing/renaming).

It was a bit the same we did for the editable, searchable, required layers lists which were moved as flagd in QgsMapLayer (89830f6)

I can go for a more descriptive phrasing, like ConfigurationFlags, would it sound better?

[elpaso]

but if that is a property that the user sets I have some doubts it's the right way to go.

yes, it's intended to be set by the user.

I would keep them separate

So you would add a new list as a property of the layer?

No, as long as it is clear what the flags are and they are homogeneous this is probably not necessary.

Can you make a preliminary list of what settings will be stored as flags (you mentioned server configuration flags such as exposure as wms/wfs and the like).

I like the idea of moving this to field because the information is where you need it, you already have iterators for the fields.
It avoids having to keep the lists in sync with possible changing fields in the layer (adding/removing/renaming).

It was a bit the same we did for the editable, searchable, required layers lists which were moved as flagd in QgsMapLayer (89830f6)

I can go for a more descriptive phrasing, like ConfigurationFlags, would it sound better?

Yes, that makes it clearer.

[nyalldawson]

\warning these will be totally broken on some python versions 😆

[nyalldawson]

Suggested change

	* Returns the Flags for the field (searchable, …)
	* Returns the Flags for the field (searchable, ...)

I'd skip the unicode characters in dox -- it's likely to open up a world of hurt

[nyalldawson]

I'm not against storing extra stuff in QgsField (e.g. I'd like to add an optional QgsNumericFormat value to it at some stage). The tricky bit is handling expectations from users who assume that changing the field's flags will automatically do ... something...! You'll need to add a massive /warning note to the dox to state that changing the flags doesn't actually change the layer settings, and point users to the correct api to use to actually set these flags on the layer/provider level.

I'm also wondering... I get the love for enum classes, but I'm thinking it's just too premature to use these widely. Could we hold back on that until post QGIS 3.16 when we do the proposed massive dependency requirement bump?

[3nids]

Can you make a preliminary list of what settings will be stored as flags (you mentioned server configuration flags such as exposure as wms/wfs and the like).

I think it would make sense to bring WMS, WFS. Editable could come to mind (it can be discussed if it's related to widget or field).
But the scope will be limited to searchable here.

[3nids]

I get the love for enum classes, but I'm thinking it's just too premature to use these widely. Could we hold back on that until post QGIS 3.16 when we do the proposed massive dependency requirement bump

Since this preliminary work is required, I would propose to no publish them in the PyQGIS API, only in C++ (until 3.18). Sounds like a plan?

[elpaso]

@3nids sorry if it's unrelated, but there is a pending issue where you were mentioned that might be related with the enums, would you please have a look? #38393

[elpaso]

Can you make a preliminary list of what settings will be stored as flags (you mentioned server configuration flags such as exposure as wms/wfs and the like).

I think it would make sense to bring WMS, WFS. Editable could come to mind (it can be discussed if it's related to widget or field).

Can we separate the server specific flags from the desktop flags?

Or maybe we need a more complex struct and use the same "origin" or "domain" concept similar to what we have for constraints?

WFS editable can be both a field property of a remote WFS that we are accessing from the desktop and a user-settable flag that we set for a field in a project that will be served from QGIS Server.

What I was trying to say with my first comment is that we should possibly avoid to mix the flags that are user-configurable and those that are "hard" coming from the provider that cannot be overridden by the API (if a remote WFS field is not editable there is nothing we can do about it but in case we are designing a WFS for QGIS Server it's up to us to decide if a field is editable or not)

But the scope will be limited to searchable here.

Is that different from queryable ?

[elpaso]

mmm actually queryable in WMS context applies to the whole layer so it might not be a good example, I'm not sure if we want to propagate layer properties to the field flags.

[3nids]

What I was trying to say with my first comment is that we should possibly avoid to mix the flags that are user-configurable and those that are "hard" coming from the provider that cannot be overridden by the API (if a remote WFS field is not editable there is nothing we can do about it but in case we are designing a WFS for QGIS Server it's up to us to decide if a field is editable or not)

I understand your point now. Last commit renames the flags to ConfigurationFlags and I added some text in the docstring.

For searchable, this flags is here mainly for the active layer features locator filter, to determine in which field it can search by default.

[jgrocha]

@3nids For Python users, we are tagging excludeAttributesWms and excludeAttributesWfs as deprecated, without an alternative. The alternative fields().configurationFlags() is not exposed yet.

Do you see any inconvenient to expose field.configurationFlags() or fields().configurationFlags() write now?

[jgrocha]

@3nids For Python users, we are tagging excludeAttributesWms and excludeAttributesWfs as deprecated, without an alternative. The alternative fields().configurationFlags() is not exposed yet.

Do you see any inconvenient to expose field.configurationFlags() or fields().configurationFlags() write now?

On the current master, excludeAttributesWms() and excludeAttributesWfs() are returning an empty set.

layer = iface.activeLayer()
layer.excludeAttributesWfs()
set()
layer.excludeAttributesWms()
set()

[3nids]

I made a PR to fix the deprecated methods: #40602

Regarding the availability in Python, I am waiting on the bump on the requirements to have a more recent sip to avoid issues with scoped enums.
The window to have this by 3.18 is getting tight, not sure when it will happen.

[jgrocha]

Thank you @3nids for your prompt answer and for #40602