QField Feature Requests

What is the problem you are trying to solve? In QField, multi-select Value Relation dropdowns successfully display and group checked items when reviewing a previously saved/plotted feature. However, this behavior breaks when creating a brand-new feature while utilizing the "Remember Last Value" pin. When a field worker creates a new feature, the data carried over from the previous feature is active in the background cache, but QField treats the new record as completely blank visually. The carried-over items remain scattered throughout long lookup lists (e.g., a list of mixed species in forestry or biodiversity monitoring). Users are forced to scroll extensively through the entire list just to see what data has carried over or is already checked. In mixed environments (like woodlands containing a combination of conifer, broadleaf, native, and non-native trees simultaneously), splitting the data into cascading parent/child dropdowns isn't a viable workaround. What is your proposed solution? Update the user interface behavior within multi-select lookups so that carried-over data from the "Remember Last Value" cache is treated identically to pre-existing row data. When a new feature form opens, these active selections should automatically pin to the absolute top of the list view. This enhancement should: • Create a visual partition on new features: Group all carried-over/active selections at the very top of the widget immediately upon form creation, with the remaining unchecked options listed cleanly below them. • Preserve project sorting: Maintain the project's underlying sort order (such as alphabetical order or custom priority columns configured in QGIS Desktop) within those two separate blocks. • Update dynamically: Refresh the list order cleanly every time the dropdown widget is tapped open. What is the value of this feature? This fixes a major UX consistency gap between editing old features and creating new ones. It aligns QField with modern mobile UX standards, dramatically reduces form scrolling during rapid data collection, and eliminates critical data validation errors caused by carried-over selections being hidden deep within large lookup datasets.

As a plugin developer, I want a documented way to create and save a feature with the layer's default values and constraints applied, as QField's form does, so that guided data-collection plugins keep working after QField updates. Example: our field teams map plots and record farm work with a plugin that guides them step by step. One button asks what they want to record, records the shape (an averaged point, a walked boundary or corners), then asks one question per screen and saves. The layer's form holds the rules we rely on: a default value that builds a plot ID from the collector's code, the farm and a running number; a hard constraint that blocks saving when the collector code is missing; a soft constraint that warns when a new boundary overlaps one already recorded. To get those rules applied, the plugin creates its own QfFeatureModel and QfAttributeFormModel and calls create(). That works well, but these classes are not part of the documented plugin API, so we currently have turn off QField updates on the phones and test each new version before allowing it. What would make this stable: Document (and keep in the plugin tests) creating, filling and saving a feature with defaults and constraints applied, for example a small helper that takes a layer, a geometry and attribute values and returns the constraint results. A documented call to open the add-feature form for a layer with a prepared geometry, with a signal when it is saved or cancelled, as a fallback. A way for a plugin to ask for positions to keep coming while the screen is off, so a boundary can be walked with the phone in a pocket. Happy to test pre-release builds.

description: When collecting data in the field with one hand, the save button (✓) is at the top left of the object form. This is particularly true for subforms that are opened from the relationship editor. With the thumb of the right hand, it cannot be reached either in portrait or landscape mode. This is particularly noticeable when working processes with many linked objects, for example with several photos per area. There, the second hand must be added for each individual entry. Android's back button or back gesture has no effect on subforms and is therefore not a solution. Suggestion: A setting under “User interface” that displays the save button at the bottom right of the form, or alternatively a floating save button. Additionally or alternatively: The back button saves and closes a subform if all mandatory fields are valid. Environment: QField on Android (Samsung), relationship editor with a linked photo table.

As a user, I want the images to keep the size as small as possible with as good a quality as necessary so as not to unnecessarily overload storage spaces. Today the average size of photos taken with QFIELD could be reduced by two via compression.

As a QField project designer, manager, and field surveyor, I would like to be edit multiple features more efficiently. Currently, when a feature list is open and contains multiple features, if the burger menu is selected then an option to 'Toggle Feature Selection' is at the top of the options. When enabled, individual features can be selected. Once one or more features are selected, the user currently has to select the burger menu again to select the editing option, e.g. Delete, Duplicate, etc. It would be a better UX to first have the toggle appear next to or even in place of the burger menu, and then when at least one feature is selected, the menu opens (would be best displayed as buttons in the list header) with the same options that are in the current burger menu, e.g. Delete, Duplicate, etc. It would save extra taps on the interface.

As a QField project designer, project manager, and field surveyor, I would like additional functionality from the temporal controller to improve the review, interpretation, and quality assurance of data both in the field and the office. User Interface While in Browse Mode: Temporal Filter Toggle An on/off toggle button should be available under the burger menu (similar to the location of Digitizing Settings when in Digitising Mode). Temporal Filter Controls When enabled, temporal filtering controls should appear as an overlay at the top of the map canvas. Filter Types The temporal controller should support three filter types: 'Calendar' | 'Rolling' | 'Custom' Switching between filter types should automatically update all associated controls and temporal ranges. 3.1 Calendar Filter The Calendar filter is intended for reviewing records by calendar periods. The following controls are displayed: 3.1.1 Period Selector with options: | 'Current' | 'Previous' | '[N] Ago' | Where: Current refers to the current calendar period. Previous refers to the immediately preceding calendar period. '[N] Ago' uses a spinner control allowing the user to select any value ≥ 2 and refers to a single calendar period offset from the current period by N units. For example, '2 Ago' + 'Months' would refer to the calendar month two months before the current month. 3.1.2 Time Unit Selector with options: | 'Day' | 'Week' | 'Month' | 'Year' | All periods are based on calendar boundaries. Examples: Current Month Previous Week 10 Days Ago 3 Years Ago 3.1.3 ☐ 'Include subsequent records' checkbox Displayed only when 'Previous' or '[N] Ago' is selected and controls whether the filter applies only to the selected calendar period or to the selected calendar period and all subsequent records up to the current date. For example, when enabled with the current date of 02 Sep 2026 and '2 Ago' + 'Years' selected, the filter would start on 01 Jan 2024 and end on 02 Sep 2026, but if it was disabled with the same options then the filter would start on 01 Jan 2024 and end 31 Dec 2024. 3.2 Rolling Filter The Rolling filter is intended for reviewing records over continuous periods relative to the current date. The following controls are displayed: 3.2.1 Duration Selector | 'Last [N]' | Where N is selected using a spinner control allowing the user to select any value ≥ 1 3.2.2 Time Unit Selector | 'Days' | 'Weeks' | 'Months' | 'Years' | Examples: Last 7 Days Last 12 Weeks Last 18 Months Last 5 Years The filter range is automatically calculated relative to the current date and time. For example, if the current date is 02 September 2026: 'Last 42' + 'Months' would display records from: 02 Mar 2023 → 02 Sep 2026 No additional "Include Later Records" option is required, as rolling periods inherently extend to the present date. 3.3 Custom Filter The Custom filter provides full manual control over the temporal range and includes an enhanced version of the QGIS temporal slider (similar to the existing proposal at https://ideas.qfield.org/app-feature-requests/p/temporal-controller ). 3.3.1 Filter controls The following controls are displayed: | [Filter Start] | [double-ended temporal slider] | [Filter End] | The filter start/end values would use calendar and time picker widgets. A dual-ended slider should: Automatically update when the start or end date-time is adjusted. Automatically update the date-time widgets when the slider is moved. Be constrained either by: a project-defined minimum and maximum temporal extent specified in QGIS Project Properties; or the minimum and maximum dates present within temporal controller-enabled layers. Changes made using any filter type should automatically update all other temporal controller widgets to reflect the resulting temporal range. The Custom filter is the only filter type that exposes direct time-of-day controls. This allows users to analyse data at sub-daily resolutions where necessary. 3.4 Time-of-Day Filtering For Calendar and Rolling filters, the default filter period should always cover the full day: 00:00:00 → 23:59:59 This simplifies common field-survey workflows and avoids unnecessary complexity. Where time-specific filtering is required, users can switch to the Custom filter type. QGIS Integration Ideally, the same functionality should be implemented within QGIS so that project designers, analysts, and field staff have a consistent temporal filtering experience across both desktop and mobile platforms. This would ensure that temporal filters configured and tested in QGIS behave identically when used in QField.

Sometimes when I log in to the app, I seem to be logged in, but I'm actually not. Only after collecting data and trying to synchronize does the app show a message saying that I'm not logged in. It would be great if this information were very clear on the app's home screen!

Search bar allow to make calculations and keep the result to paste it elsewhere. This functionality isn't available anymore when a subform is open, or a form in fullview mode. It would be glad to be able to make those kind of calculations inside numeric fields for example.

The QFieldCloud Sign In dialog opens behind the active project window. It should open on top of the active project window. (Win 10)