Following up on my own post with a solution (or sorta)
Thanks to Christian for a possible steer - it was in the right direction...
 
Short answer is - the vcardcategories must have data that, in some cases, 
prevents display of the record in iOS. (It displays fine in Sogo and 
MacOS/carddav.)
I found multiple records which had the same categories, some which would 
display on iOS and some that wouldn't.
 
For example:
In the ldif record there'd be a field for vcardcategories: myContacts - two 
different records would have the same vcardcategories ("myContacts", in the 
cases I individually identified)
with the same exact text. One would display on iOS, one wouldn't. 
 
However, if you edit the record in Sogo (that wouldn't display in iOS) and 
simply removed the vcardcategories entirely, and saved the record, suddenly 
that record would show up in iOS.
 
After spending some time attempting to see how they were different, and simply 
not finding ANYTHING that would distinguish why one would display and one would 
not, I gave up.
 
- I exported all the records from Sogo as LDIF.
- Text edited them to remove all vcardcategories from the records entirely. (In 
this case, they were superfluous.)
- Then deleted all the address records from Sogo and re-imported the edited 
LDIF without vcardcategories.
At that point, every carddav record (I believe - This isn't my address book, 
it's a client.) now shows up in iOS without issue.
 
(The vcardcategories on these records came from a Google address book, 
initially - which was exported and then imported into Sogo - if that matters.)
 
<shrug>
I got nothin' - no idea why it worked this way. 
But at some point, you gotta give up and just apply the big hammer, I guess.
 
If anyone else has iOS display issues, I'd strongly recommend looking at 
vcardcategories.
If someone at sogo would like to examine the LDIF, confidentially, in an 
attempt to grok the issue, I could probably provide it.
 
Belated thanks to the Sogo team for the great product, and again to Christian 
for a pointer at what might be involved - it was, though perhaps not quite in 
the way anticipated.
 
-Greg


> Hello

>> FN:Jim & Joe Blow
> or

>> displayname: Jim & Joe Blow
> must be set.

> As that is the case, the only unusual thing is

>> CATEGORIES:Imported on 8/28,myContacts

> Do you really have a category "Imported on 8/28"?
> I never tried a category with a "/" character in it.


> Kind regards,
> Christian Mack

> Am 14.07.21 um 00:57 schrieb Gregory Sloop ([email protected]):

>> I think so...
>> So, I'm using the web ui of SOGo to look at a (one example) contact that 
>> displays in MacOS's address book, and in SOGo - but not in iOS.

>> I'm going to sanitize the data, since this is a real contact.
>> I get this by using the "view raw source" item in SOGo.
>>  
>> BEGIN:VCARD
>> VERSION:3.0
>> FN:Jim & Joe Blow
>> N:Blow;Jim & Joe
>> EMAIL;TYPE=INTERNET:[email protected]
>> TEL;TYPE=HOME:509-123-4567
>> TEL;TYPE=CELL:510-123-4567
>> ADR;TYPE=HOME:;;101 Joe Blow Dr;San Lorenzo;CA;94580;us;101 Joe Blow Dr\,San 
>> Lo
>>  renzo\,CA\,us\, 94580\,United States
>> NOTE:Mobile Phone: 510-123-4567\n
>> CATEGORIES:Imported on 8/28,myContacts
>> UID:40-60BFBB00-23-E8D87C0
>> END:VCARD
>>  
>> (I think FN is the display name (full name) - though I can't find a fields 
>> definition anywhere...)
>> I'm not sure what UID is, though I suspect it's a hash of the SOGo user ID 
>> and the ID of this particular contact. But I assume there's nothing in that 
>> that should raise an issue.
>>  
>> Dumping the record as an LDIF is somewhat different...
>>  
>> LDIF dump from SOGo web UI
>> ---
>> dn: cn=Jim & Joe Blow,[email protected]
>> objectClass: top
>> objectClass: inetOrgPerson
>> objectClass: mozillaAbPersonAlpha
>> description:: TW9iaWxlIFBob25lOiA1MTAtNDYxLTc0MjkK
>> st: CA
>> displayname: Jim & Joe Blow
>> mozillahomepostalcode: 94580
>> mail: [email protected]
>> c: us
>> vcardcategories: Imported on 8/28
>> vcardcategories: myContacts
>> sn: Adams
>> homephone: 509-123-4567
>> mozillahomestate: CA
>> postalcode: 94580
>> mobile: 510-123-4567
>> givenname: Jim & Joe
>> l: San Lorenzo
>> mozillahomecountryname: us
>> mozillahomelocalityname: San Lorenzo
>> mozillahomestreet: 101 Joe Blow Dr
>> street: 101 Joe Blow Dr
>> ---
>>  
>> Is there anything useful there that might help steer me closer to 
>> identifying the issue?
>>  
>> -Greg
>>   


>>> Hello
>>> Do all your addresses have a display name set?
>>> Kind regards,
>>> Christian Mack
>>> Am 11.07.21 um 20:40 schrieb Gregory Sloop ([email protected]):
>>>> Anyone? 
>>>> Even general hints at where I might start would be appreciated!
>>>>  
>>>>  
>>>>> So, I've got a setup where I migrated an addressbook from Google/Gmail 
>>>>> into sogo. (Exported the contacts from Google and imported that export 
>>>>> file into that users' contact list.)
>>>>> I've got a MacOS client, iOS client and the Sogo web-front end all 
>>>>> pointing at the same sogo/carddav contact list.
>>>>> Changes (add/delete/modify) on any of the clients (MacOS, iOS, Web) all 
>>>>> are reflected in all the views - so I know all are pointing at the same 
>>>>> contacts list.
>>>>> On the MacOS and Web (sogo) clients, all contacts show fine (are all 
>>>>> visible).
>>>>> However on iOS, some contacts are simply missing.
>>>>> If I were to guess, there's some field that has a value that's causing 
>>>>> those records to be suppressed on the iOS client. (But no errors at all 
>>>>> from the iOS device.)
>>>>> But I have absolutely NO idea how to go about troubleshooting this.
>>>>> I don't have a complete list of all missing contacts - though I have 
>>>>> identified one - so at least I have an example to work from. (If you have 
>>>>> any ideas about how to do this via script or programmatically that would 
>>>>> be fab. But it's not as important as figuring out what's going wrong.)
>>>>> So, anyone have good ideas about how you'd go about running this down? 
>>>>> (The more detailed the better, because I'm way out of my depth here.)
>>>>> If it matters, I'm using Sogo as configured into Mailcow.
>>>>> Thanks!
>>>>> -Greg



-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x121
EMail: [email protected]
http://www.sloop.net
---
-- 
[email protected]
https://inverse.ca/sogo/lists

Reply via email to