I would like to suggest a small but useful feature enhancement regarding tags.
Use case: I want to create a tag to mark individuals that I have found in a public database (e.g. INSEE in France, etc.). This tag would be used exclusively for filtering purposes — for example, to quickly build a filter set like “show only individuals found in external databases”.
The problem: Currently, every tag requires a color, and that color is applied visually in the graphical tree view and in the individuals list. I already have other tags that apply meaningful colors to certain individuals, and I want to preserve that visual display. Adding a new tag with any color would either override or interfere with the existing color coding.
The request: It would be very helpful to be able to create a tag with a “no color” or transparent option, meaning:
The tag would carry no visual color and would not affect the background color of an individual in any view (list view, graphical tree, etc.)
It would still be fully usable in filters and reports
It would coexist cleanly alongside color-bearing tags on the same individual
A workaround is to set the tag color to white, but this is fragile (depends on the theme background)and not semantically clean. For instance, in the graphical tree view, setting a tag to white overrides the default gender-based coloring — males are normally displayed in blue and females in pink. With a white tag applied, that distinction disappears entirely for the tagged individuals, which defeats the purpose of the existing visual encoding.
This would be a low-impact change — essentially allowing a null or none color value for a tag — but it would significantly improve the flexibility of the tagging system for users who use tags both for visual marking and for data classification.
Why not use an Attribute instead of a Tag? I strongly suggest using Attributes for characterizations that are permanent. And Tags for temporary use or added visibility in views
Attributes may not have a Filter gramplet field, but you can use a custom filter:
Thank you for the suggestion. I am aware of Attributes and their use, but I prefer Tags for this specific use case for a practical reason:
In the Individuals list view, Gramps allows you to display a dedicated Tags column directly in the list (via View → Configure View → check “Tags”). This gives me an immediate visual overview of which individuals have been found in a public database, without having to open each person’s record.
With an Attribute, this quick at-a-glance overview in the list view is not possible — you would need to open each individual record or build a custom report to achieve the same result.
So my workflow is:
Tags for both filtering and quick visual identification in the list view column
The tag I want to add for “found in public database” should ideally be filter-only, with no color impact on the graphical tree or the row background in list view
This is precisely why the feature request makes sense: the ability to create a colorless tag would allow tags to serve a pure data-classification role when needed, without interfering with the existing color-based visual encoding (e.g., gender colors in the graphical tree view).
A new tag has the color black (#000000) and theoretically the same color of the text to be colored. But the default color of text is set by your theme and may not be pure black.
I did a test by editting the uncompressed backup xml file setting the color of a tag to “”. Imported the modified backup into a new database with no ill affect.
Truthfully, I use tags for filtering only and never use tags to disply colors in reports or graphics. I do set certain tags with a color so in a list the color is displayed to alert me to a certain status of the record. I have never had the need to say the default color of a tag is getting in the way of my research.
Regarding colored tags, the color will only make itself evident when that tag is the first in the list of tags. Maybe the thing to look at is the ordered ranking of your tags.
I consider an “external [public] database” is a source and I create a record for it, with a somewhat arbitrary repository.
Whenever I add data from such a database, I fill in a citation, notably containing a backlink to the information so that it is one-click accessible.
I “show only individuals found in external databases” by going to the References tab of the Source corresponding to the database.
Taking the example of the French “INSEE” DB, the repository is MatchID with a generic link to site deces.matchid.io and …/search/?advanced=true for Web Search property.
Source gives a label and description to the database and a “special” Note adds /id/ to the URL inherited from Repository.
Every citation has a “special” Note adding the permalink id to the end of the URL inherited from Source.
I mention “special” Notes because I have customised Gramps to try and struggle against Internet rot where supposed-to-be-permanent URLs are not that permanent. URLs are split into fragments attached to Repository, Source and Notes. They are recombined at each level to synthesise the final URL. The goal is to have to patch as few records as possible when a change occurs.
The same approach works for sites created by other amateur genealogists. Thanks to the Citation record, I can assign a confidence level to every reference.
Thank you for testing this — it is very helpful to know that an empty color is already handled gracefully.
Could you clarify whether it is possible to modify the tag color directly in the database files, or is it necessary to go through the full export → edit XML → reimport workflow?
Regarding the priority ordering workaround: it works well for my events, since I have already tagged all of them with another colored tag — so the “found in public database” tag would always be second. However, it does not fully solve my problem for individuals, because not all of them have another tag assigned. For those individuals, the new tag would be first in the list and would therefore impose its color, overriding the default gender-based colors in the graphical tree view.
This is why a proper “no color” option in the tag editor would still be a valuable addition. That said, even if the development team does not wish to implement this feature officially right now, I would already be very happy to have it working on my personal database — so any guidance on how to achieve this locally (whether by editing the database directly or patching a source file) would be greatly appreciated!
Edit :
I managed to achieve the “no color” tag directly by editing the Gramps SQLite database. Here is how I did it, in case it helps others:
Prerequisites: Gramps must be closed before editing the database.
Navigate to your Gramps database folder (typically ~/.gramps/grampsdb/) and open the subfolder corresponding to your family tree
Make a backup copy of sqlite.db before doing anything — just in case
Open the file sqlite.db with DB Browser for SQLite (or any SQLite editor)
Go to Browse Data and select the tag table
Find the row corresponding to your tag
Clear the content of the color column
Also edit the json_data column to set the color field to an empty string: "color": ""
Save and close DB Browser, then reopen Gramps
The tag now has no color and does not override the default gender-based colors in the graphical tree view, nor the row background color in the individuals list view — while remaining fully functional for filtering and visible in the Tags column of the list view.
This confirms what was suggested earlier in this thread: Gramps already handles an empty color value gracefully, it is just not (yet) exposed in the UI. Hopefully this can make its way into the tag editor as a proper “no color” option in a future release!
Thank you for sharing your approach — it is well thought out, especially the URL fragmentation strategy to fight against link rot, that is really clever.
However, in my case, using a Source record does not quite fit my need. My goal is not to document where the data comes from for a specific piece of information (birth date, death date, etc.) — I already use citations and sources for that purpose. What I need here is simply to flag an individual or event as “seen in a public database” at a glance, as a quick research status indicator, without necessarily implying that any data was actually imported or modified from that source.
In other words, it is more of a research workflow marker (“I have checked this person against public database X”) than a proper source citation. A tag fits this use case much better, as it is lightweight, instantly visible in the list view column, and usable in filters without adding documentary weight to the record.
I also use tags to visually hint at my research status. There is some kind of ordering between my tags, which could compare to building confidence in my data:
completely new record (I only read a mention of the person, event, family, … somewhere)
partial data collected (birth or death for person, marriage or some children for family, partial description for source, …)
missing source (records have been lost, destroyed, burnt and further research is hopeless)
legal restriction (evidence is temporarily unavailable due to legal delay on data communicability – just wait)
In my workflow, only one of these flags can be assigned. Each has a different colour.
When a person or marriage is considered “complete”, the remaining flag is removed and record display “normal”, i.e. black. I consider “missing” as a final status (equivalent to “complete”) when I am convinced I won’t find any further evidence about the record.
I also added a “check” flag to draw my attention on records where obviously I made mistakes or I have a serious doubt about consistency or reliability (e.g. because of age discrepancy or homonymy). This flag is not exclusive of others but I consider it takes precedence over the others.
Therefore, I carefully ordered my flags so that I get the “most important” colours in the lists. Ordering is then: check (first), new, partial, lapse, restricted.
In principle tags are metadata related to the research not to the data. I broke this rule with yet another tag called “No posterity” (which theoretically should have been an attribute). I assign it to people who died too young to reach marriage or never “married” (in Gramps parlance, i.e. had no “fruitful” relationship) and to families without children (with proven evidence).
The reason why I did this is I modified the Family Lines graph generator to add a tag-coloured border around people and family boxes to give me a quick visual hint. “No posterity” is thick gray and clearly shows dead ends. “No posterity” is at lowest priority in order not to interfere with status flags.