QGIS: Password-protecting Layer Properties / Attribute Forms (Plugin idea, know-how wanted)

[COFT_TEAM]

Hello everyone,

we are currently facing a structural challenge in QGIS and would like to find out

1. whether others are experiencing a similar issue, and

2. whether there are people with the technical know-how to help implement a solution (e.g. a plugin).

Problem description

At the moment, QGIS does not provide a way to lock specific parts of the Layer Properties - in particular the Attribute Form - so that:

• contents cannot be viewed

• and cannot be modified

• ideally protected by a password

This becomes especially problematic when QGIS projects are shared with clients or project partners, either for review only or for limited editing.

In practice, the following issues occur frequently:

• Layer Properties (e.g. Attribute Form, Relations, Symbology, Labels etc.) are accidentally modified

• as a result, QField projects or forms stop working correctly

• sensitive information (e.g. internal IDs, logic, helper fields) becomes visible to everyone, although it is not intended for all users

Goal

Specific parts of layers and projects should be protected so that:

• the project structure remains stable

• sensitive information is not visible

• QGIS projects can be safely shared without loss of functionality

Proposed solution

Our idea is a QGIS plugin or a core QGIS update that allows certain parts of a project to be password-protected, for example:

• Attribute Forms

• Relations

• Default Values

• Symbology

• possibly additional properties

The locking mechanism should be optional and configurable per layer.

Implementation ideas

Option 1 – Protect Layer Properties

Right-click on a layer → Layer Properties → select a specific section (e.g. Attribute Form)
→ password prompt before the Attribute Form is displayed
(see screenshot “Layer Properties – Attributes Form”)

Option 2 – Project Properties / Data Sources

In Project Properties → Data Sources, there is already a “Private” column for layers.

Idea:

• extend this concept to specific property sections

• e.g. “Attribute Form = private”

• additionally, the Project Properties themselves would need to be password-protected

(see screenshot “Project Properties – Data Sources”)

Transferability / Added value

Although our immediate use case focuses on the Attribute Form, such a plugin or update would be much more broadly applicable:

• protection of other project views

• safeguarding complex QGIS/QField setups

• relevant for planning offices, public administrations, and GIS service providers

If technically feasible, we would be willing to cover development costs for a plugin.

Previously used workarounds

So far, our approach has been to provide clients or project partners with a copy of the QGIS project in which sensitive information was removed from the Attribute Forms. However, this comes with significant drawbacks: once these elements are removed, the project can no longer be properly edited, as essential components such as default values and form logic stop working. In addition, this approach prevents access to and editing of the associated QField project.

Using the QField Desktop application comes closer to our goal, but it also has limitations, as certain features (e.g. map tips) do not function correctly. Moreover, our long-term objective is to hand over the final project files to clients or partners, while retaining access only for maintenance or troubleshooting - something these workarounds do not adequately support.

Questions to the community

• Are you aware of any existing approaches, plugins, or core discussions addressing this topic?

• Is this type of access restriction realistically achievable via a QGIS Update?

• Are there QGIS plugin developers interested in discussing or collaborating on such a solution?

We appreciate any feedback - both from users facing similar challenges and from developers who can provide technical insight or possible solutions.

Thank you very much and best regards,

COFT-Team,
Philipp

[cuprico]

Just an opinion of course (as a user and not a developer); I think most of these issues not only can be addressed by a change in approach, but also that trying to go this way might be overcomplicating and potentially risky/unsafe. A couple of issues first:

1. When implementing a protection/security/safeguard, you have to define acceptable risks such as attack vectors, tolerable failure, possible attackers, etc. Given that, you might come to the conclusion that having the files, even if encrypted, is having access to the information within (given enough time and effort).
2. Having a badly implemented protection mechanism might lead to a false sense of security. How critical is to keep this information private?
3. If the security of the information really is a concern, any proper implementation should factor security audits. Going with an in-house implementation is highly discouraged, always prefer battle-tested, well established implementations.
4. How compatible is the proposed approach with the ethos of open-source, free software? You are after all using QGIS and QField, yet inherently proposing to hand over closed information to your costumers. You have your copy of the project to do as you please, to modify it, to study it, and redistribute these modifications; why shouldn’t the costumer also have these rights?
5. Why is the sensitive information stored inside of the GIS data? Does it really have to be, or is it just convenient?

These questions are mostly food for thought, not trying to attack you. Having said that, some ideas off the top of my head as starting points for discussion:

QField gives you the ability to trim the data before “export”

As a first measure of “protection”, you can choose which layers to export to the QField project and which to keep in your local QGIS desktop project. You can’t exploit or alter data you never had. Layers are cheap, can be duplicated and pass data between them.

You can have separated projects for internal and external use

QGIS already has an amazing capability for separating the data from it’s representation (datasets vs. project files/sources,etc.). You can update your data privately on your internal QGIS project, and link the same datasets (Geopackages, geotiffs, SHP, KMLs, etc.) to another, more simplified project. If there isn’t already a plugin for that, I think you might be better served by a tool that helps you automate that, if it is too much of a hassle.

Maybe consider using databases

I feel like much of these problems can be better solved by user access management on the database level, rather than on QGIS. From creating layer filters associated with user credentials to access a PostGIS database, to a fully fledged GeoServer instance with proper WFS/WMS permissions, there are a lot of options to consider. Hell, even the Geopackage is just a specialised SQLite database file, fully capable of being extended. Maybe if you don’t care too much about protecting the data, you can probably come up with a way to encrypt it in place; either by a function before writing or by passing the file to a tool afterwards.

Have you considered version control?

If you want to better deal with potential misconfigurations, I think that working with some version control system might be a good solution. The .qgs project format is just XML, so it might already be well suited for Git. This should help you to easily and conveniently get a known working state for your projects, give you the ability to audit changes and even add some user permissions set up. Combined with remote DBs for the datasets, it can even work as a way to deliver your products, just send a lightweight .qgs project with some additional README and documentation along with it.

[Jeroen-GroeneBij]

Interesting questions, Philipp.

My first instinct is the same as @cuprico, why protect or hide something in an open source ecosystem. And, why would data be sensitive to the client, assuming it is their data.

I think your questions should be separated in at least two sections. Datasets (tables) that contain sensitive data and Layer properties that contain sensitive data. For each, it would help to get an even better understanding (examples) of sensitive data in your usecases.

Let me focus on the layer properties part.
To put my ideas in perspective, I believe in educating the client, so they will be able to maintain and possibly improve the project, or at least understand to keep away from project settings and don’t change anything that has to do with layer or project properties. Any change can grind your project to a halt.

Some clients don’t want to maintain the project, they want you to be the caretaker. In those cases, the client might not even need the QGIS project, they may only be interested in the resulting data and or resulting maps.

I am not a developer but all layer properties are stored in the .qgs file and or a .qml file, which are plain text files. So anyone with access to the.qgs file can read any setting in the layer properties and project properties and I am not sure this can even be hidden from users. The exception is the implementation of database access profiles, where profile information is encrypted in some manner.

So for example, if you have come up with a very clever expression (ip?) for a default value, anyone with access to the .qgs file can read and copy that expression. If the expressions use hardcoded sensitive data in their statements, this is visible in plain text.

There is good value in a project structure that can not be tampered with, but anyone with access to the .qgs or the project in QGIS can change anything. So probably the best approach is to restrict that access. I am fairly new to QFieldCloud organisation settings, but there will probably be an option to restrict users from making changes to the project and only be able to edit the data.

[fggs-pascal]

For accidental changes, there is a way to restrict which layers or fields can be edited via expressions:

You could write an expression that checks if @cloud_username is in a list of users who are allowed to edit. For a high number of users, this will still be finicky to maintain, though.

I agree with the previous commenters. If it’s a security thing, I think you have to make sure the data doesn’t even end up on the user’s device, which means either separate projects or datasource-level restrictions.

[COFT_TEAM]

Hi everyone,

thank you all very much for the thoughtful replies, perspectives, and concrete suggestions — we really appreciate the time and experience that went into this discussion. A lot of the points raised here were valuable and helped us reflect on our approach.

We’d like to take a moment to clarify and slightly reframe our original intention, as our main goal may not have come across clearly.

First of all: we strongly support the values and ethics of open-source software. We are long-time users of QGIS and QField precisely because of their openness, transparency, and flexibility. Our intention is absolutely not to create a closed environment or to restrict user rights in principle — the goal is purely to improve project handover stability in real-world workflows.

Regarding the “security / hiding information” aspect: this was actually not the core of our request, and we already have practical workarounds in place for that part. For example, we routinely create external project copies and remove sensitive data that partners do not need. We’ve also already applied some of the common approaches mentioned here to ensure that sensitive information (if it must remain in the project) is not unnecessarily exposed to external users.

So the remaining challenge we are trying to solve is much more specific:

Preventing accidental changes (not security)

In our daily work, we often hand over QGIS projects to clients or partner offices who do need to edit data and who rely on fully functional Attribute Forms (default values, expressions, relations, automatic logic such as intersections, etc.). These forms must remain active for the project to function correctly — but at the same time, they are very easy to unintentionally break.

A single modified expression, default value, widget configuration, or relation setting can break QField/QGIS workflows and lead to significant troubleshooting and repair work afterwards — often causing frustration on both sides.

We also fully agree that client education is valuable and we support that approach whenever possible — however, in reality many clients do not want (or cannot invest in) deeper QGIS training, so a lightweight safeguard against accidental changes would still be very helpful in day-to-day project handovers.

Some of the suggested approaches are already known to us or have been tested, such as:

• trimming QField exports,

• separating internal and external projects,

• database-based permission models,

• and expression-based control of field/layer editability (e.g. via QField / QFieldCloud user context).

These can definitely help, but in practice they can become hard to maintain (especially with changing staff, new users, or many project partners), and they don’t fully address the risk of someone accidentally breaking the form logic itself inside the Layer Properties.

That’s why what we are really exploring is a lightweight UI-level safeguard, not a security mechanism:

Lock UI sections (e.g. Attribute Forms) to prevent accidental changes

Even a simple password-based unlock for specific UI sections would already go a long way for us. If a client explicitly wants to modify form logic and feels confident doing so, the password can be shared — similar to protecting individual sheets or ranges in an Excel file.

Thanks again to everyone who contributed — your input is highly appreciated, and it has helped us clarify what we’re actually looking for.

We would still be very happy to receive any further ideas or suggestions that could help us solve this remaining “accidental changes” issue.

Best regards,
Tommy,
COFT-Team

[Jeroen-GroeneBij]

Tank you Tommy for reading through all the long answers and refining your question.

I absolutely agree that forms, and styling in general, is very easy to unintentionally break. And that customers are not always willing to put effort into learning how not to break this.

I can see the benefits of locking the styling in many use cases, QGIS wide, however I can’t see what possible downsides this might bring. It would be great to discuss this with the broader QGIS community.

Looking at your question from another angle, how about a way to easily restore a broken styling. I have not tested this or looked into this any deeper, but here are my thoughts.

The form is part of the styling, which is saved in the .qgs, but can also be saved as a separate .qml file. The styling for each layer is saved to a separate file. The .qml files can easily be applied when the original styling has been broken. The .qml files could be set to read-only, so the customer always has a copy of the original styling including forms on-premise.

The styling can also be saved to the geopackage containing the data and set as default styling for any specific layer. Whenever you add a layer to a project, that default style will be applied. Maybe, the styling element in a geopackage can be set to read-only, I don’t know about this.
And maybe, maybe, there is a way to get QGIS to respect a default styling per layer defined in a geopackage as read-only, so any changes made to the styling is not saved in the .qml, but in the default style in the geopackage, which, when set to read-only, will give an error or warning. This probably needs changes in the GeoPackage standards and a way to set and unset the read-only attribute.

A styling can also be saved to PostGIS. That might also be a source for a read-only style.

There are plugins that will reload default styles for all layers within a project, using different methods.

All this does not prevent changes being made, but offer ways to repair a broken styling.

Another idea would be to have like a memory for styling. The map layout has something like this where you can lock layer styling (18.2.2. The Map Item — QGIS Documentation documentation)
Maybe a plugin can make a copy of the style for the entire project and save that as a read-only within the project or within a geopackage or PostGIS or any server?