Improve Contributor Role

[oakey-dev]

Is your feature request related to a problem? Please describe.

It would be nice to extend the Contributor Role so that a Contributor can edit any records that he himself has created.

Additionally it would be good if one could grant permissions to others (Contributor or higher) to also edit those objects.

Describe the solution you'd like

Adding a reference to objects for the creator and possible editors.

Describe alternatives you've considered

Granting Editor permissions to different people can be an issue if the number of family tree editors gets larger and there are some people that don't like others in the family and hence could edit or remove something of theirs.

Splitting the family tree into multiple Trees may work but in the end I'd prefer to have a single family tree.

Additional context

[DavidMStraub]

Interesting, so unlike #597, which is about fine-grained viewing permissions, this one is about fine-grained editing permissions. It's also closely related to gramps-project/gramps-web#899.

I see two general issues:

1. Due to Gramps' architecture, it's unlikely we'll ever be able to have permissions based on object creation. While in theory the transaction history in Gramps Web allows to reconstruct who first created on object, the Gramps database itself does not contain this information.

2. So far, the permission system assumes that anyone who is allowed to modify the database (contributor or editor) requires acces to view all records. This is because view restrictions are based on Gramps proxy databases, which provide a filtered view to a database. This ensures the permissions are enforced at database access level and cannot be violated by buggy application code. But those proxy databases are not writable.

So right now, we have

Group	View	Add	Edit
Guest	Restricted	no	no
Member	All	no	no
Contributor	All	yes	no
Editor	All	yes	yes

Even if we introduce fine-grained permissions (at object level) for viewing or for editing objects, we cannot have users who can add (or edit) some objects, and also view only some objects.

So, in your scenario, if you have some people in a family branch who don't like other people from the other branch, would you want them to see all data from the other branch? I guess not.

[DavidMStraub]

AI generated recommendations - the filter-based approach is what I was also leaning towards.

https://gist.github.com/DavidMStraub/5a7f1f4b1e374db4445baa93654b88f4

[Mambouna]

So if there were a Gramps filter that given a person outputs all persons who are either their partner or children, then the biggest blocker of the implementation would be done? If I find time some time soon I might take a look at that. I'll first have to look how complex it would be to create new filters.

[DavidMStraub]

Any help is welcome, but creating the filter is not the (main) problem - changing our architecture to support filter-based permissions needs lots of work (& careful thought).

[oakey-dev]

In my case I don't want to limit the visibility

[Mambouna]

Any help is welcome, but creating the filter is not the (main) problem - changing our architecture to support filter-based permissions needs lots of work (& careful thought).

Ah okay, now I understand. If this is deep in the architecture, then it might be too much for a first foray into the codebase for me. If there's other stuff to help with around the sides though, I'd be happy to step in.

[sipkin19]

Adding context from #779 (Family editor), as suggested.

Use case: A role that can view the whole tree but edit/delete only a scoped subset — e.g. the user's "root" person plus ancestors up to grandparents and descendants down to grandchildren. Goal: let relatives maintain their own branch without being able to change the rest of the tree.

Difference from "edit only what I created": We don't need "creator" on objects. Scope is defined by the relationship graph (root person + N generations up/down), which Gramps already supports. So this is "edit only objects that belong to my branch," not "edit only objects I created."

View vs edit: We're not asking to restrict view — the user would still see the full tree (no read-only proxy change). Only writes would be restricted: in the API, before each create/update/delete, check whether the object (or the person/family it's tied to) falls inside the user's allowed scope; if not, return 403. So this would be an application-layer check on write, not a writable filtered DB view.

Happy to align with whatever direction the filter-based approach takes; just wanted to document this variant (view all, edit subset by relationship scope) in the same discussion.

[Mambouna]

I guess this reopens the question of whether it is appropriate to create a front-end solution based on restrictions on what calls will actually be made or if this should be implemented as a structural feature in the back-end to just be consumed afterwards.

I think long term a solution in gramps itself would definitely be preferable. Is it realistic for this to be achieved though? From what @DavidMStraub said a proper solution in Gramps itself would be complex and require rework of existing features. If a solution that is simply enforced via the front-end for Gramps-Web specifically would be a lot easier it might be appropriate. At the same time, if a full solution is made at some point in Gramps, this could lead to redundant work in Gramps-Web. Maybe an implementation could be pursued that leaves the UI changes sustainable? Basically trying to have a central way to check whether the operation is legal which could be swapped out with relatively little pain later if the underlying solution is made possible?

Sorry for the speculation, just trying to think through the possibilities.

[DavidMStraub]

I guess this reopens the question of whether it is appropriate to create a front-end solution based on restrictions on what calls will actually be made or if this should be implemented as a structural feature in the back-end to just be consumed afterwards.

I don't think this question is opened: restrictions in the front end are not restrictions at all. Any security-relevant feature MUST be implemented in the backend. And this is an issue in the backend repo, so it's the right place.

I think this feature would be very, very valuable. But I see it as a second step after introducing fine-grained view permissions, see #597. Both of these are tricky in many ways but not impossible.

[oakey-dev]

I actually like the "Family editor" description from above.
Possibly implementing it based on that could be easier as it wouldn't need so larger changes to the permissions system I'd assume.