I’m planning to host GrampsWeb for my extended family to collaborate.
Due to divorces and privacy reasons I’d like to block parts of the tree from distant relatives.
For example, I have a parents A and B. People on the A side of the tree shouldn’t be able to see people from side B.
I’m aware of the privacy option but unless I misunderstand that, it’s not quite what I’m looking for.
Yes, this is a well-motivated use case and would be a huge improvement. Unfortunately, it is difficult to implement with Gramps’ current architecture and data structure. I’m sure we’ll get the “some day”, but not soon.
Right now, the only way is to set up to separate trees I’m afraid.
I have implemented something like this for NarrativeWeb.
The pages are generated with a special <meta> element containing a list of “privacy keys” (~ lineage name). My Nginx configuration has a location block to intercept all requests to NarrativeWeb pages and submit them to a separate “filter” script. The script checks that the authenticated user has a key (in its configuration database) matching one of the “privacy keys” of the <meta> element.
If there is a match, the page is returned without the <meta> to avoid security leaks.
If there is no match (or user is not authenticated), a login-like form is sent. Login is valid only 15 minutes to protect against replays or spoofing.
Pages without <meta> are public.
Modification to Gramps is minimal: you just associate a custom attribute to a record. This custom attribute is transformed into an HTML <meta> during NarrativeWeb generation. The effective filtering is done outside Gramps in an Nginx hook by a small perl script accessing an SQLite database.
Presently, this is rather a proof-of-concept working on Person and Family. I have not designed a finer-grained filter where Events could be hidden inside an otherwise public Person page.
Note my implementation is different from your request: NarrativeWeb pages are “frozen” and can’t be updated online. It builds a “read-only” site, not a collaborative one.
You’re right that the privacy option isn’t the option to use, but you’re close. Gramps does support a powerful “Filter” system that can divide the family into two halves. In fact the privacy option is a “proxy” that is built on top of the “Private Filter”. In fact any filter can be a proxy.
Currently, the only way (in core Gramps) to use a Filter as a Proxy is in the Export options, but it should be fairly straightforward to make gramps-web use it, as it can use the Private proxy.
Anyway, if you wanted to use gramps-web today, you should be able to:
Perhaps others can add more details to these steps as I haven’t used these operations before.
Thanks for the ideas.
As a first step I think I’ll try to create a privacy filter in core gramps per @dsblank, and once that is working as expected, try to modify the GrampsWeb API to use that filter. Maybe using @pgerlier’s idea of attaching lineage keys as an attribute.
@pgerlier for your privacy / lineage keys are they automatically generated? Or do you set them manually on a per object basis.
My keys are manual. This gives be more freedom. Consider for example what happens with pedigree collapse (two lines join on an ancestor). I give then two keys to allow people on both branches to access the record.
More generally, the key is space-separated list of ids telling “who” is allowed to access the record. Users in the authentication database are associated with a list of ids telling which records (or “lineages”) they are entitled to. Intersection of record key and user “rights” must not be empty to unlock access.
I found this approach less restrictive than a strict lineage strategy. Some users may be active contributors and it would not be fair to restrict them to their own lineage. Therefore, their “rights” contain more than one id so that they browse various parts of the tree.
Within a Gramps tree, Attributes can be shared. In simple cases, I have one attribute which is assigned to several persons or families. This takes care globally of common situations. It is also easy to modify this single attribute and the change is effective on all sharing records at once.
Hi,
using filters is something that has been considered in the past, but there are some challenges. Let’s use this issue that was just opened Limit access for user to main person and relatives · Issue #597 · gramps-project/gramps-web-api · GitHub to discuss implementation details. @kltigers it would be awesome if you could take this on, but let’s chat in the issue about the options to avoid redundant work.
In any case, this has long been a pain point and would be super useful to many users without doubt.
One of the unexpected uses of filters in the Destop version is in Charts. As an example, consider the Fan Chart.
Here, the filter does not hide the person from being display in the chart. Instead, the colors a muted for the filtered out people. So you might want to highlight the lines of descendency from a particular ancestor to illustarate pedigree collapss. Or highlihht ancestors with a particular attribute (like immigrants or military service)
The highlighting filter is useful. But I’d like to be actually able to redact with filters in charts too.
Just something to keep in mind if you implement filtered data.
It’s not about implementing filtered data - the list views already support filters - it’s about filter-based permissions, so filtering out at the database access level (but the existing FilterProxies are not sufficient).
I understand that. List view filters work the same way on Desktop. So the requested familial and privacy filtering might fold in seamlessly in list views … once you get past the other isdues.
But I’m just mentioning that the Chart views have a idiosyncratic filtering that might create another complexity.
Gramps usage is “ambiguous”. It is a tool but many people want it to be a “universal” tool.
From my point of view, Gramps is primarily a data-entry tool interfacing a DB storage and a report creation tool. I never consider it a public display/browsing tool. I delegate this role to second-level apps after creation of a display-oriented excerpt, e.g. NarrativeWeb navigated through with a web browser.
In its data-entry role, Gramps is unrestricted. This is perhaps because I am the only one to make changes in it. The topic is different with Gramps Web in collaborative context.
I can restrict what is exported in NarrativeWeb with privacy flag, but this is rather coarse, and definition of persons of interest. I solved selective access with my hook in Nginx where I intercept the page sent to client. I analyse <meta> parameters according to rights in a dedicated DB and decide whether or not the page is forwarded. In case of lock, the page is replaced by a login one so that user is not surprised.
So, discussing about selective access is related to the capability of supporting simultaneous access in Gramps, which is not possible presently.
@pgerlier well, this post is in the Gramps Web category of the forum, and simultaneous access is at the very core of what Gramps Web is about.
Yes, I agree this question is not relevant for Gramps (desktop) as there is no need to handle permissions in a single-user desktop data entry tool. And that’s also the reason why it’s tricky to implement the OP’s request, because Gramps hasn’t been designed with that use case in mind.
Oops! I did not pay enough attention to the tag (well, it displays in light gray below the title, thus it is rather inconspicuous). Please accept my apologies for being slightly off-topic.
However, could my trick be adapted to Gramps Web? As I already mentioned, it is external to any data source. It is located in the server configuration, checking page contents as they are being returned. The only requirement is to provide an ad-hoc <meta> element.
I also considered (but discarded it because it requires deep modifications) to play at <div> level. This would allow to discriminate parts of pages so that Events or Notes could be “protected” in an otherwise public Person, Family or Place.
I don’t think it makes sense for us to filter at the frontend (HTML) level as the pages are generated dynamically based on HTTPS calls to a REST API. But we would also need a separate database for the rights (an Access Control List, basically) if we go beyond privacy only, because even if we opt for a filter-based approach, it will likely be too slow without pre-computing the access rights per object.