When I list the events I see that there are a number of them that have no first or last name (see picture).
These events are already referenced in the database and assigned to individuals (with another event identifier number).
I guess I have to do some wrong manipulation sometimes to get these events with no first or last name created.
Does anyone have any idea where these entries come from in the database?
I donât think itâs that because I donât use roles (yet) so theyâre all primary for births and deaths.
I realized that contrary to what I was saying some of these events are not listed elsewhere in the database.
I will therefore come back here after having analyzed these âghostâ entries in detail.
Please double check these events in the Personâs or Familyâs edit windows. The only way the Main Participants would be empty in the Event list is if the personâs Event Role was NOT Primary or a Family event was NOT Family. Any other Role setting will cause what we are seeing in the event list.
If you can tell us that the Role for these events do have the Primary roles, then we will know that something else is at play.
Note: Editing an event from within the Event view will NOT display a personâs (or familyâs) role. Roles can only be seen from within the personâs or familyâs edits and views.
The roles are set at event creation but in editing an event by copying and editing, it is not uncommon for the role to be set to âUnknownâ.
I donât think Roles are the are the cause of this problem. But you are under a misimpression that needs to be corrected. Correcting it later may let the problem grow too imposing.
Roles often surprise starting users⊠but only when they start causing problems. They arenât even aware of Roles before that.
Because:
they donât realize Roles are required , &
Gramps is so automated in creating Roles (based on context) in the normal sequences of adding records, that the Role feature goes unnoticed⊠until there is a Role that is wrong.
To clarify, if a default Role type can be determined when created by context, then it will be.
As examples: adding a NEW Event (with the '+â icon) uses the Context of the Editor. Within the context of the Family Editor, defaults the Role to Family (with implied Roles of Bride & Groom). Within the Person Editor, defaults the Role to Primary.
However, without that context (as when in the Event view) adding a NEW Event has an UNKNOWN role.
And sharing an Event (whether by dragânâdrop, the Share button/menu item, or clipboard) does not provide any context or the context is ambiguous. So the Role would be set to UNKNOWN there too.
I got bitten by this in 2 spots before learning about roles:
sharing Birth Events for twins & triplets.
re-cycling Events that were made redundant by a Person Merge
The most blatant Role problem is when no Birth (and/or Death) appears in the on-screen summaries for a person even though there is a corresponding Event in the Person Editor. (Such summaries might be for the age at Event or indicating the lifespan in the Relationship or Chart views.)
Iâve had a similar problem that I need to finish isolating for a bug report. [report has been filed]
It had to do with the stack of parent/child window spawned by Gramps and dismissing them out-of-sequence.
You can get buried under a slew of windows. (In Relationship view, add parents, add mother, add birth Event, add unknown Place, add encoding Places. You may have at least 6 spawned windows on-screen now.
Say that you âOKâ the spawned windows, in the correct Inverse sequence, back to & including the Birth Event. This leaves the mother Person Editor & Family Editor window on top of the Main Gramps window. (Plus any detached Gramplet & possibly the Clipboard.) If you accidentally click the Family âOKâ first, it pops a warning about unsaved (the mother, although that isnât identified) and asks if you want to Save. You breathe a sigh of relief and click OK.
Something weird happens. Those New Events might have been created with the previous OK click but they werenât attached to the new mom yet. Or the Mom get created but wasnât attached to the Family. Or both. You expected Gramps to layer the Saves from the mostly deeply spawned window⊠but it loses is place too and just kills the sub-spawned windows.
Since the spawned Family window disappears, you donât even notice the missing bits.
Or you DO notice and say to yourself: âI couldâve sworn I created that!â Then figure you had just lost your place (because youâve got Gramps, Ancestry, FamilySearch & WikiTree up along with the scanned Reference book and youâre trying to manually harmonize them all simultaneously) and re-create the missing record. But if you had switched over to the View for that type of record & sorted by âlast modifiedâ, you would found the orphaned record.
Interesting.
Curious to see the rest of your investigations.
I have never used creating events in Event view or sharing events.
I didnât even realize that you could create events in Event view.
Thank you for the clarifications you provide on the subject of the roles.
For my part, unfortunately I could not (try) to analyze the anomalies of my database and do tests until this weekend.
I just had time to remove the âghost eventsâ which I could definitely call âduplicateâ.
Maybe a lead (but maybe itâs a coincidence), for these I shared a medium between the birth and death event (for the majority of stillbirths where the death certificate also serves as a birth certificate).
I will therefore come back this weekend with, I hope, more details on the cases that I encounter.
I come back a little early.
What you describe with the multiple open windows speaks to me.
Often in simple consultation but it happens to me sometimes to make modifications in this situation.
I have looked at my âghostâ events and almost all of them are events that I (for one reason or another) deleted.
So if I put one with the other I have the impression that in order to try to reproduce the supposed bug we would have to put ourselves in a situation with several open windows and delete one or more events.
On the other hand we can see on the image that I had posted previously that I had 16 âghostâ events which represents a very low percentage compared to those I have in the database and when I look the modified years are distributed between 2018 and 2020: it is therefore very sporadic.
I still have two, related to the same individual, where Iâm not sure I can conclude a deletion if you look at the modified time:
Interesting discussion.
This will be included in the next version of Gramps if I understand correctly (like on Mantis youâre talking about changes you made in 5.1.2 and I didnât find it on 5.1.3)?
To be clear, when you delete an event from a person or family does NOT delete the event from the database. An event not attached to a person or family will obviously not display a main participant in an event list.
There is a Remove Unused Objects tool to delete these no longer needed events (or anything else, so be careful).
The feature request still needs one of the programmers to take up the issue. I have offered up the basic code that would need changing but there are other areas that may need to be changed to fully implement the request.
You can take my changes and modify your own code as I have done. But until it is set in the code, you would need to modify each new version of Gramps as they become available.
If you edit the event (or any other object) there will be the References tab. This is the list that shows what other object the record is linked with.
There are some oddball cases. There can be notes with the Type âTo Doâ that are part of the To Do Gramplet. These notes may or may not be attached to another object. The Remove Unused Object is written to ignore these notes. The same with notes with Type âLinkâ. Notes that are Linked internally to another note but not attached in a way to produce a Reference.
The English text says âRemove the selected personal eventâ in the Person editor. It does not delete the event. After all, you may want to add that event to another person.
At least once a week I Remove the Unused Objects concentrating on Events, Citations and Notes. I know I have objects in the other areas (mostly Places and Sources) that I have added but not yet attached to other records. I do the remove weekly so that I have a chance to remember why these records are ready for deletion.
And you may need to run the tool three times because there may be a citation attached to the event you are deleting. Or a note attached to either the event or citation. These will not show up for possible deletion until the other objects are deleted first.
You CAN delete an Event from within the Event list View. There, the minus sign [ - ] does say delete and not remove. The same is true for all list Views.
This is what I wanted to say but I was not comprehensive enough.
You are right to say so.
I take this opportunity to say that I find that the icon with the â-â sign is also ambiguous outside the Event view.
I imagine for example, but there are surely better, two pieces of puzzle assembled or separated to represent the current â+â and â-â in this case (and to keep + and - in the event view).
This definition of âremoveâ is not consistently observed. In fact I filed a bug report last week on one example. Itâs in the Graph View where thereâs a contextual menu option to âRemoveâ a person. Upon selecting it, you are warned about deleting the person. (I realize this doesnât contradict what @DaveSch is saying about list views.)
This is not good.âą
I like the use of âdetachâ thatâs being implemented in this thread vs âremoveâ. The former is pretty clear that the Event (or whatever) isnât going away, whereas âremoveâ sounds like it might (and in fact at least in the case I mentioned, it does). (I canât comment on the French. )
Itâs also bad UI to have the same icon mean more than one thing, which is what I take @zebulon to be saying. The minus sign should mean either detach the item or delete it, and not change depending on context. Thatâs confusing.
I wonder what people think then of two things:
Clean up the language. Remove is ambiguous, so donât use it. Personally Iâd like something else like âdetachâ as @zebulon has offered. But at least never use it as a synonym for âdeleteâ.
Create a different icon for âdeleteâ. A trash can seems the obvious choice. You can even use this in combination with detach.
OK, a third thing: donât use a minus sign as an icon at all. Itâs ambiguous. In addition to the trash can maybe some kind of separation symbol, like the broken link in the editor when a URL is removed? I have the icon labels turned on, so I can see clearly that it means delete in a list view, but not everyone does.