Hi, The fact that the parent event is still shown is a design decision that we have made as relationships are not inherited by parent events. Whether or not to show this event, or to have relationships inherited is something we will consider, however further investigation is needed to make sure what we decide covers all users of the program and how they use it. The workaround at the moment would be to also make the parent event have relations with the entity. However when you group by Entity and then filter out all the child events, we agree that the parent event should not appear in that Entity group anymore, and therefore will look at changing this for a future update. Jess
Hi, I think I was not clear enough, in my comment I wrote that it makes no difference wether the Parent has a relation with the filtered Entity or not, the Parent remains visable, your workaround does not work, that is just the issue. Thank you will take notice of this in a future update.
Hi, Sorry about misreading your comment. You are right, if the parent has a relation with the filtered entity it should not remain visible. If it is possible, it would be helpful for us if you could send your timeline through to email@example.com, with a description of which filter you are using, which event is not disappearing and the operating system you are using. .This would help us find the problem quicker. We keep all timelines confidential. Jess
Fiction template: If I have a parent with three children events, and the Location/Place of each of those events is different, and there is no Location information in the parent, when I group by Location the parent shows in all three groups along with the appropriate child. If I only want to see the child in the grouping, but not the parent (since the parent does not contain explicit Location information), is there a way to do that? Sometimes I want to see the parents, sometimes I don't, depending on what I'm trying to do...doesn't seem like there is a way to control this behavior.
Hi, There is no way to control this behaviour at present. We made the decision to always show the parent regardless of the filter or group so that the parent hierarchy was always clear to the user. It seemed like we would be hiding information inappropriately by making the event appear as it if it a top-level event. That said, making it an option or providing more flexibility is something we can definitely consider in the future. Alternatively, we could make it so that parent events automatically inherit relationships from their children. So if any child of an event has Location X, the parent would also share that Location (potentially among others). This wouldn't really change the current behaviour, but would make the 'inherited relationship' clearer in the Inspector so that the behaviour is not as unexpected. Jess
Thanx. Adding the design decision behavior somewhere in the user's guide would be helpful.
Ooops...hit return too soon. I'm wondering if I have my data and entities 'incorrectly' set up...suppose I have a list of events for world war 2, and one entiti
sorry...trying again...suppose I have three WWII events which cover different portions of war, and they each have many children showing the battle events. The parent events have lots of aspects (fields, entity types) that are common to their children, hence the setup as parents. For the children,, there is an entity category showing battle type: air, sea, land, sub. If I want to see just all the air battles, I can’t as I bring along the parents of each air battle along with the child event. Perhaps my parent child design is incorrect for what I’m trying to accomplish?
Hi, Due to the way we have the filter set up regarding parents, it does sound like you won't be able to use it in the way you want for your current setup. One thing I can suggest is that instead of having your three parent events to cover different portions of the War, turn these events into an entity type instead (eg. if you had an entity type called "Portion of War", and then three entities of that type called "Portion 1", "Portion 2", "Portion 3" - you can probably come up with better names then me. If for what you had as child events before, you can now assign them the portion of the war that they belong to by assigning them this the appropriate entity. Then you can group by this entity type (the three horizontal bars in the top right of the tool bar). This will align the events in the vertical space by the portion of the war they belonged to. So when you filter by something like air battles, you will only see the correct events, but they will still show wha t portion they belonged to. This is just a suggestion for a way to get around the problem for you, hopefully it gives you the same functionality that you needed, while getting the filters correct. Jess
Thanx...I hadn’t gone down that path before as I was trying to avoid having to assign x organizations related to a portion and y people related to a portion to each event in that portion(perhaps a paste would work), but cumbersome. Will ponder. Going back to my original desirement, I suppose I could offer that allowing a filter to exclude parents that didn’t satisfy the criteria could be an important feature of the iOS version of AT...since screen real estate is often at a premium. Thanx for the discussion.
For my situation, I would have some 300 portions with 4 or 5 events per portion and some subset of 30 persons, typically 8, per portion (this set of persons would be applicable to all events a particular portion). I want to avoid assigning people to each event as would be very repetitive. Being able to not display the parent per above seems like my only ‘easy’ way out, so will hope for that feature in a future release.