Five questions about jtxB use of properties and their parameters

[rogercreagh]

Just trying to clarify what to expect from the server with various properties. All relate to VJOURNAL components only.

1. Does jtxB ever use multiple DESCRIPTION properties for a entry (eg multi-language). It is specified as allowed but I've never found it used (but then I only speak english really - and I suppose american which is different).?
   What would jtxB do if it found a second DESCRIPTION property? - I think the right option is to ignore ones after the first but preserve them and sync them back as-is after the item is changed. I'll be delighted if you say never used!

2. Does jtxB correctly preserve and write back to the server all unrecognised property parameters it finds? eg reference another discussion if I started adding LABEL parameters to attachments to hold a caption or title for the attachment would you preserve it? And in general for other property parameters? I hope so!

3. I see jtxB is allowing multiple attendees for a VJOURNAL item, but each attendee only has CN, CUTYPE and ROLE parameters but no value after the colon. The value is specified as a cal-address URI, typically a mailto: address. This could be useful if you are using the attendee property to save contact details of people participating in some aspect of the journal entry. It would mean adding a field to the data entry for the attendee. I'd like the option to add a uri.

4. Is there a reason why you are using CONTACT property but not ORGANISER given that you are using ATTENDEE and SEQ (which is an optional property? Organiser seems to be primarily concerned with Vfreebusy which obviously doesn't apply to Journals, but it is also mentioned in the explanation of sequence number. jtxB sets seq to zero - would it ever use it or change it? How and when given there is no organiser to change it? I don't really care but if you are never using seq it would seem sensible not to include it unless you find it already set in which case preserving it.

5. Does jtxB ever create or use Timezone related properties? Or does it assume always local or UTC time?

Sorry for so many questions, no rush for answers.

[patrickunterwegs]

Hey @rogercreagh

Does jtxB ever use multiple DESCRIPTION properties for a entry (eg multi-language). It is specified as allowed but I've never found it used (but then I only speak english really - and I suppose american which is different).?
What would jtxB do if it found a second DESCRIPTION property? - I think the right option is to ignore ones after the first but preserve them and sync them back as-is after the item is changed. I'll be delighted if you say never used!

Actually I wasn't aware that multiple DESCRIPTION properties would be possible. That's even a bit hard to make it fit into the current structure.
As this was never considered, I'm afraid the logic would just take the description and put it into the database field. I'm afraid if there is another description, the previous description would be overwritten and lost...

Does jtxB correctly preserve and write back to the server all unrecognised property parameters it finds? eg reference another discussion if I started adding LABEL parameters to attachments to hold a caption or title for the attachment would you preserve it? And in general for other property parameters? I hope so!

Yes, there is a logic that preserves unknown properties. Parameters are preserved for properties that are considered to occur multiple times like attendees, attachmetns, ... For simple properties where ususally no parameter is expected, the parameters are currently not preserved. But I also haven't come across any .ics where such parameters were used.

I see jtxB is allowing multiple attendees for a VJOURNAL item, but each attendee only has CN, CUTYPE and ROLE parameters but no value after the colon. The value is specified as a cal-address URI, typically a mailto: address. This could be useful if you are using the attendee property to save contact details of people participating in some aspect of the journal entry. It would mean adding a field to the data entry for the attendee. I'd like the option to add a uri.

If you enter text in the field, the app would add the information to the CN field. If you enable access to your address book and you select one of your entries, the CN would be the name and the cal-address would be the email-address (if there is one).
But yes, we can think about offering two input fields for CN and for the cal-address!

Is there a reason why you are using CONTACT property but not ORGANISER given that you are using ATTENDEE and SEQ (which is an optional property? Organiser seems to be primarily concerned with Vfreebusy which obviously doesn't apply to Journals, but it is also mentioned in the explanation of sequence number. jtxB sets seq to zero - would it ever use it or change it? How and when given there is no organiser to change it? I don't really care but if you are never using seq it would seem sensible not to include it unless you find it already set in which case preserving it.

The organiser field is considered in the background, but I have never made it visible. I was not sure how to deal with it, if it should automatically set it to the owner of the collection or if it should be an input field to be set freely. Given that insecurity I kept it hidden.
The sequence is used and updated (+1) every time an entry is saved (which can be multiple times while editing if autosave is on). When synchronizing the entries with a server, the conflict handling is done by the sync app (DAVx5). But when you import .ics files locally, jtx Board needs to check which entry is the newer one in case of conflict and would take the one with the higher sequence.
Additionally the sequence is used to check wheter a recurring entry was changed. Changed recurring entries must not get updated anymore when the series changes.

Does jtxB ever create or use Timezone related properties? Or does it assume always local or UTC time?

Sure, you can create entries with a time in any timezone (DTSTART, DUE, COMPLETED).

[rogercreagh]

The organiser field is considered in the background, but I have never made it visible

If it is set I think it should be visible somewhere even if only readonly (and maybe labelled as 'owner') together with the created and modified dates. It should also be sync'd - it doesn't appear at the moment.

[patrickunterwegs]

I agree with you, but still, the two questions are the same. Would you allow editing it?
The owner might be confusing, it could be the collection owner (which will be visible in the collections overview from jtx Board 2.4.0). So I'm just thinking, if it's always the collection owner, the field doesn't really make sense and doesn't add any value. It would only make sense if you offer it as an input field and let users add any value (or a structured value with CN and cal-address...)

[rogercreagh]

For simple properties where usually no parameter is expected, the parameters are currently not preserved.

Hmm, so eg if I set a parameter on description (eg altrep or language) you wouldn't preserve it? I think there are params on properties that can occur only once which might be significant.

[patrickunterwegs]

Yes, in your example the parameter would get lost for the description.
If you decide to use something like that, I'll have a look how to change it best.

[rogercreagh]

I agree with you, but still, the two questions are the same. Would you allow editing it? The owner might be confusing, it could be the collection owner (which will be visible in the collections overview from jtx Board 2.4.0). So I'm just thinking, if it's always the collection owner, the field doesn't really make sense and doesn't add any value. It would only make sense if you offer it as an input field and let users add any value (or a structured value with CN and cal-address...)

Yes, I see your point, but I'm wondering whether it might be useful to know in a situation where multiple people are sharing the same journal. So it should be not the collection owner but the person who originally created it - the current user of the device it was created on - and should not be easily editable (like created and modified dates). Hence display it with the dates and sync it as organiser.
Some applications might even use the created-by/organiser to limit editing, or notify the original creator when it was modified by someone else. (future idea)

[patrickunterwegs]

It absolutely makes sense as you describe it. But DAVx5 currently doesn't provide the information about the user that is logged in. That might be an enhancement for the sync. (This option could also provide the technical information about the person/account). On the other hand for jtx Board it is not so relevant who's the actual owner. For local entries you are always the owner. For remote collections it's the server and DAVx5 that tell jtx Board if an entry should be read only or not. On entry level there is no rule (that I know of) to tell if the user is allowed to change it or not.

An alternative would be to set up a global organizer field as a preset. jtx Board 2.4.0 will have preset options to define preset categories and resources. There could be an organizer field where the user could globally define who should be mentioned as organizer. What do you think about that?

[rogercreagh]

Yes defining a global organiser field would work.
As a default how about using the device name as the organiser (CN only) - I guess you can access that? - which would work if the user didn't bother to set the global.
What happens now if an item coming from sync has an organiser property - does it override the internal one (possibly desirable but not essential), or does it get silently noted and reflected back unchanged (very desirable if not used), or does it get dropped and not reflected back on the next outgoing sync (not good)?