QField Feature Requests

We are working with naturalists on the field pointing species. For each observation, they have to select an name through thousands of species. The Reference value widget works perfectly well but it is still time consumming, especially when they often search for the same species. This could be faced with an hybrid of the unique value and the reference value widget. We thought about two options : A dropdown with unique value (P1) The unique values listed before anything is typed (P2) On both cases, once something is typed the widget behaves as the reference relation (P3). This can look like a strange workaround, but that would really save a lot of time for us on the field. The hybrid widget might not be the best solution, if something better is found we'd love it too!

In the attribute form, when searching in a reference value, we have trouble with accented letters. In our case this is about french letters (especially é, è, ê), but this might be usefull in other languages too. Example with the linked pictures : Qfield doesn't recognize 'Mésange' if one writes 'mesange'. It doesn't seem much but it creates a lot of friction on the field.

### Context We maintain a downstream fork of QField tailored for field vegetation surveys in Poland (WorkField), so first of all: thank you for the new in-app NTRIP client — it removes a whole layer of third-party mock-location tooling for RTK workflows and has been working nicely in our tests. ### Current behaviour Looking at src/core/positioning/ntripclient.cpp and positioningsource.cpp , when the caster connection drops or errors out, NtripClient emits errorOccurred() / streamDisconnected() and PositioningSource records the state — but no reconnection is attempted. The client is only (re)started when the receiver connection state changes, so after a transient network hiccup the user has to toggle NTRIP manually. ### Why it matters in the field On cellular connections in rural areas, short drops (handover, coverage gaps) are routine. Each one currently silently degrades the fix from RTK back to autonomous until the surveyor notices and reconnects by hand — easy to miss while collecting data. ### Suggested behaviour Automatic retry with growing backoff (e.g. 1 s doubling up to ~30 s), gated by the isPermanent flag that errorOccurred(message, isPermanent) already carries — permanent errors (bad credentials, unknown mountpoint) would stop retrying and surface to the user, transient ones would retry quietly. We would be happy to prepare a PR along these lines if the approach sounds right to you.

Can we pleasehave an option to install plugins via zip from local storage.

When multiple users edit the same GeoPackage project from QGIS desktop via qfieldsync, there's currently no real protection against one user's sync overwriting another's changes. QField mobile already has a real conflict-resolution mechanism for this class of problem, but qfieldsync doesn't participate in it. Using postgres instance to deal with that problem could be a solution but in some cases it's more inconvinient than it seems to be. I needed a fix quickly for self hosted deployment and prototyped a stopgap: the desktop client remembers the file version it last synced, sends it on upload, and the server does something similar to a three-way merge of the GeoPackage instead of overwriting. It works, but I wonder if building a separate custom system instead of reusing your existing delta/conflict approach is a good final architecture. Is integrating the desktop client into your delta pipeline something you're planning? If you're open to it, I’d be happy to contribute and start off a discussion on how to approach it.

Currently, only one photo can be taken per input. The workflow is currently: Set the 1st point Open the attachment widget, Create and save environment photo 1 Create and save environment photo 2 ... Add detail photo 1, save ... Set the next point. I'd like to take multiple photos with the same attributes (except for the path). So z.B. Set 1st point Open attachment widget Create and save environment photos 1-5 Create and save detailed photos 1-3 set the next point.

Currently, by default, there is no way to add charts from project data in the print layout (in QGIS). However, charts can be created using HTLM code with QGIS expressions. Unfortunately, QField does not currently support HTML code with QGIS expressions. It would be great if this functionality from QGIS could also be adopted in the QField.

For a vector layer with multiple features, I would like to be able to show or hide on the map in QField all features within that layer. I know one can show or hide the whole layer on the map but that is not what I am looking for. The reason for this is that I have a vector layer with lots of features. Sometimes I want to see all the features but other times I want to see only one or a few of the features. In QGIS if I have a vector layer that is categorized, I can click on “hide all items” and then click on each feature I want to see. And if I want to see all the features, I can click on “show all items”. But currently this is does not seem possible in QField. See my post about this https://community.qfield.org/t/show-hide-all-features/1788 .

Many Qfield projects use photos as field evidence. However, these photos could be very useful for other projects. The Panoramax open field photo sharing platform seems like the ideal place to share these photos. Especially since the Panoramax plugin is now available in Qgis: the photos can therefore be used directly. Several ideas: a Qfield plugin to allow sharing directly add a checkbox “share the photos of this project on Panoramax” when creating a Qfield project mount a Panoramax instance to more easily navigate through all the photos already accessible in open QFieldCloud projects/send future photos sent by contributors

QGis snapping configuration is applied to the active layer. In this way, if we want to set different configurations (in that case : overlap) to different layers, it is not possible. In our case : a land use layer (we don't want any overlap) a polygon observation layer (we want to allow overlap) A good way of solving it would be to add a toggle for overlap on the digitalisation settings, exactly like it is done for the snapping (cf. the picture linked). This solutions was proposed by nirvn here : https://github.com/opengisch/QField/issues/6410