Merge pop-up menu choice for the Clipboard?

Navigating to all the Category to select known duplicate objects following an initial merge is tedious and can even be difficult.

However, dragging the objects to the Clipboard and using its pop-up menu to “make the object active” simplifies the navigation process for 1 of the 2 objects.

Unfortunately, Gramps doesn’t have an effective way to leverage this Clipboard-controlled Navigation shortcut to do the extended selection of two (and ONLY two) of the same category objects needed to merge the duplicates.

Example: assume that you discover that Individuals have the same spouse are actually the same person. However, the partial information didn’t allow them to be matched until much later. So, you now have a Mr. Smith with an “about” birth year in a particular state, Note & Citation to Merge with a Thomas Smythe, born on a precise date & location, a more detailed note & a citation for a different page of the same book.

So you need to merge the men, a family, marriage event & Note.

You discover that each object is different enough from its duplicate that you cannot just navigate to one & find the other nearby. So it is going to take a LOT scrolling to make the extended selections for each set of objects.

You could apply filters for each duplicate in the example above… but that’s a lot of work for a one-off.

My workaround in the past is, after initially merging the duplicate Persons:

  1. open the Person editor for the Merged Person. (The various tabs of that dialog will have collated all the duplicates)
  2. Edit the preferred duplicate and Ctrl-C copy the ID
  3. edit the merge-candidate duplicate and paste in the preferred object’s ID plus an “a” suffix
  4. switch views the object’s category
  5. turn off the right Gramplet sidebar to enable the faster Searchbar
  6. paste the ID in the searchbar and find
  7. select the 2 records
  8. click the merge icon on the toolbar
  9. make certain that the preferred object ID & details will be the ones surviving the merge
  10. merge
  11. clear the search term & find
  12. re-enable the right sidebar

It would be so much simpler if it was possible to just drag the duplicates from the Edit Person to the clipboard, select two objects on the Clipboard and choose “merge” from a pop-up menu. (It would be nice if the Clipboard considered an Object and a Ref to an Object of the same Category to be mergable.)

Someone is sure to suggest that the Editor dialogs be changed to allow extended selection. But that would require extensive changes to many dialogs and a fundamental change to the metaphor. This requires far less intrusive changes.

Perhaps the Collections clipboard would be a good place to test?

(Another option would be to have a persistent Merge tool. It could open whenever the Merge edit menu or toolbar icon is chosen and there are more or less than 2 objects selected. Where the user drags the objects to the dialog, the detail view is the default setting and the Merge button performs the merge & clears the dialog to allow 2 more object to be dragged. An advanced option might be a checkbox that omits the Clear after the Merge. This would allow another merge-candidate of the same object to be merged, reducing each subsequent merge to 1 drag per redundancy. This newbie-friendly option would be more discoverable than a contextual pop-up menu buried in the clipboard.)

Another idea could be another default behaviour e.g. opening the person selector if you have just one person selected and press the merge button. So you don’t have find the second person nearby.

1 Like

The initial person merge is well-enough implemented “as is”

My solution (which I also use for purposes other than merging) is to have a Person Filter called “myPerson”.

In Events, I have a Filter called “@myPerson” which shows events associated with the results of myPerson.

I also have a Place filter called @myPersonEvent, which (therefore) shows Places associated with a person joined (to use Database language) via the Event object.

I also use this approach to have a primitive “myPlace”, which again is leveraged in a “@myPlace” Events filter, and a @events@myPlace Person filter.

Thus, by setting the starting Filter suitably, I can readily navigate connected Object of different types.

One thing (amongst many) this approach supports is merging Events for a defined Person.


I have done something similar with filters. However, it uses a “Filter” Tag for the Person(s) or Object(s). The Custom Filter looks for Objects referencing Persons with that Tag. This is much more efficient than continually re-aligning the filter for a specific object ID. (Although Kari’s experimental FilterParams add-on eases that burden dramatically.)

The drawback to a filtered approach is the extreme latency involved in recursively filtering all the duplicates in all the categories.

Each time a merge occurs, the Filter is re-calculated. That is slow for 40,000 Persons & agonizing for 120,000 Events.

So, a Merge navigation workflow passing through the clipboard may take seconds. Meanwhile, the equivalent workflow through filtered categories (for the multitude of merges needed for a single duplication of a Person) will take minutes or even tens of minutes.

You could use bookmarks too to do that, it’s more simple that tags I though

Could you expound upon the use of bookmarks for merge filtering?

I’ve found the usefulness of bookmarks to be quite limited. It would be nice to find another use for them.

While the bookmark menu is nice for navigation, my bookmarks are very diverse as a group. That means actions applied to the whole group of bookmarks does more bad things than good. (Unless a lot of work is done trimming down the bookmarks before the Action, and then restoring the original bookmarks afterwards.)

There are filter rules for using bookmarks:

Unlike Tags, there isn’t a Bookmark selector in the Filter Gramplet for any of the Categories.

I was only talking about bookmarks vs tags. Instead of a filter on tags, filter individuals from bookmarks. You can add and remove them with a single click.

I wonder if a Supertool script would not automate your solution.

You could add -A1, -B1, -A2, -B2, … to the IDs of the events to be merged from the individual editor and then run an ST script from the events view that would look for the IDs -An and - Bn to merge them*.
The advantage of -Xn would be that the ST script would associate together all the events with the same n and that several events defined by the same X resulting from duplicate events in the same person record could be processed at once.

The script would scan through all the events, store whatever -Xn values it finds (statement part) and then eventually merge them together at the end of its scan (filter part - if code can be executed in it ??).

Something like that:

[Gramps SuperTool script file]



def merge(gramps_id):
	if "-" in gramps_id:
		#Look if An and Bn records are stored in stored_events variable then merge them
			#Code to merge the two records
		#Else skip when both records are not yet stored
		return True
		#else skip that record
		return False

stored_events = {}

#select -Xn event records and add An and Bn records to stored_events variable







* You even can then imagine a second suffix (-dpD for date location and description to select which information to keep in the final event. For example: -A1-d & -B1-pD)

OooOOH! I hadn’t considered from that direction. I did not think of the possibility of a contextual menu for the Bookmarks menu items.

I will have to boot up the Gramps box & see if it has a “Create filter from the <object> selected…” power feature like found on the contextual menu of the clipboard.

For Tag custom filters. I go the opposite direction. I create a Tag named “Filter”. Then I created a rule in each category where it finds Object of “Filter” tagged Persons & Families.

With this, I can just Tag all the extended Family Members and apply the filter. Occasionally, I delete the Filter tag & recreate it. That clears everywhere it is applied.

I have been using a Tag MERGE for some time. I created it to make sure that I was merging the correct John Smith together so I colored it a neon pink color. But the tag is easily filterable when the wife is only known as Elizabeth.

Just remember to clear the Tag when done.

I think your objection is more strongly founded as a criticism of filter speed than of the approach to merging.

In my present database, the result of 5 years careful research, I have around 3500 Persons, and even my 12 year old laptop filters it at a perfectly acceptable rate, although I would have no objection to faster filtering

Filter speed is a significant issue with tens (or hundreds) of thousands of records. As is the recursive running of such complex filters after every action. But these aren’t the primary concerns.

But this is more of a matter of unnecessary re-navigation to already isolated/identified data within your workflow.

The Relationships view and various object editors have already collated a full set of filtered lists that make the merge candidates highly visible in close GUI proximity. And done so quickly.

Having to manually replicate these naturally occurring filters in top-level category view lists AND then manually select the filter AND finally manually run them (for EACH category) is massively redundant labor. This is substituting manual tasks for automation rather than the other way around.

That the Gramps filtering is slow merely adds insult to injury.