search

TechbeeAT / jtxBoard

jtx Board allows you to manage your Journals (like meeting minutes), Notes and Tasks in one Android app. The app is compatible with the iCal standard (RFC5545) and is integrated with DAVx5 to allow the synchronisation of entries through CalDAV.
https://jtx.techbee.at/
GNU General Public License v3.0
363 stars 10 forks source link

[Feature] Add RELATED-TO;RELTYPE=CHILD property to parent Journal items for sub Notes #492

Closed rogercreagh closed 1 year ago

rogercreagh commented 1 year ago

Is your feature request related to a problem? Please describe. Currently sub-notes for Journal items have a RELATED-TO: property set to the parent item (the Journal item) uid

However there is no corresponding RELATED-TO;RELTYPE=CHILD: set on the journal item.

This means that if you are fetching only VJOURNAL items with a DTSTART, or with a specific UID, you have no way of knowing that there are related Journal Items with no DTSTART (ie Notes)

I guess this is not a problem with jtxB as I think you are always dealing with the entire set of VJOURNAL items so will always find the child items to tie back to the parent. Are you setting the RELATED-TO child parameter for Journal items with a child ToDo?

Describe the solution you'd like If an item has a parent-child relationship with another item of the same type (eg Journal and Note - both VJOURNAL items) or a different type (eg Journal and Todo) then both parent and child should have the relevant RELATED-TO property set.

Describe alternatives you've considered Not being able to find related child items without looking through the entire dataset.

patrickunterwegs commented 1 year ago

Hey @rogercreagh , let me also convert this to a discussion. The short answer is NO, jtx Board 2.x does not set the CHILD relationship and I really don't want to bring this back.

The long answer is: When I first started jtx Board, I was thinking the same way. I thought it would make things easier when you need to show the parents or the children of an entry. So I was even physically storing both ways, the parent and the child relationship. However, this got so complicated in some places and caused so many problems, that I decided to drop the CHILD relation and only kept the PARENT. Why?

  1. When you have both relations, every time you add a new child, you also have to update the parent, which also causes an additional entry to sync
  2. The same for deletions, you delete a child, you need to update the parent.
  3. This gets particularly messy when thinking of the sync. All other apps that I know don't use the CHILD relationship, only the PARENT. When you want to use the CHILD-relationship, you need to create it artifically - which I did in jtx Board 1.x physically. Changing entries from another app just for the sake of fullfilling the needs of the own app is also not a good practice.
  4. Mass deletions through the sync are particularly hard to do, as you need to change every parent afterwards as well to update the related-to. But sometimes you just don't know which entries were deleted through the Android content provider and it's not clear if orphaned related-to entries are really orphans or if an entry is just missing.
  5. After all using only the PARENT relationship brought more advantages than disadvantages and now it works properly and reliable.

So I stronly recommend you to not use both relationship types and stick with the PARENT!