Address Book WebExtensions API: allow setting contact UID during creation
Categories
(Thunderbird :: Add-Ons: Extensions API, enhancement)
Tracking
(Not tracked)
People
(Reporter: mkmelin, Assigned: darktrojan)
References
Details
Attachments
(2 files, 2 obsolete files)
(deleted),
patch
|
mkmelin
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
mkmelin
:
review+
|
Details | Diff | Splinter Review |
Comment 1•6 years ago
|
||
I want to request to be able to Change the UID even after creation. The EAS protocol actually requires this. When a contact is created locally and send to the Server, it will return a new UID which I have to adapt.
Assignee | ||
Comment 2•5 years ago
|
||
Here's the binary changes required to do this.
Reporter | ||
Comment 3•5 years ago
|
||
Assignee | ||
Comment 4•5 years ago
|
||
Better?
Assignee | ||
Comment 5•5 years ago
|
||
Reporter | ||
Comment 6•5 years ago
|
||
Reporter | ||
Comment 7•5 years ago
|
||
Assignee | ||
Comment 8•5 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #7)
it would seem more logical to have the id as last, optional parameter so
people don't have to call this with the middle parameter null
It is optional. The WebExtensions interface checks the argument count and types and assigns null to id before calling this function.
true, but can you still add a check that the card with that id doesn't exist
already (and throw if it does?)
Reasonable, in fact I considered it but didn't do it for performance reasons when adding multiple contacts, but I guess the whole address book only needs to be checked the first time.
maybe also document that we're expecting something like a uuid, though other
forms would be acceptable, only so that people don't mis-use this to have
like id=2 or something like that.
Basically, what I think should be allowed is things that can reasonable be
considered to be unique: uuids, and uri based ids.
How do you propose to enforce that?
Reporter | ||
Comment 9•5 years ago
|
||
Open to suggestions, but maybe we want to ensure the length is at least 16 (which is already stretching unique quite far)
Assignee | ||
Comment 10•5 years ago
|
||
I don't think we can do a lot. Having a minimum length is tempting though.
This would all be a lot easier if we had address books that could only be written to by the extension that created them. Something to consider in the future.
Reporter | ||
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/254c026047c8
Allow setting nsIAbCard UID from script if it is not already set; r=mkmelin
https://hg.mozilla.org/comm-central/rev/1eaba2d214b2
Address Book WebExtensions API: allow setting contact UID during creation; r=mkmelin
Assignee | ||
Updated•5 years ago
|
Comment 12•5 years ago
|
||
(In reply to Geoff Lankow from comment #8)
(In reply to Magnus Melin from comment #7)
it would seem more logical to have the id as last, optional parameter so people don't have to call this with the middle parameter null
It is optional. The WebExtensions interface checks the argument count and types and assigns null to id before calling this function.
In what way is it optional? I can't call create
with two parameters and get WebExtensions to assign null
to id
; I'm forced to pass three parameters, aren't I?
Assignee | ||
Comment 13•5 years ago
|
||
No you're not. If you call the function with the second parameter as an object, id
is automatically null when it gets to the actual code.
The function your extension code calls isn't the function in the API code. There's a layer in between which checks you're passing in usable arguments as specified in the schema.
Comment 14•5 years ago
|
||
(In reply to Geoff Lankow from comment #13)
No you're not. If you call the function with the second parameter as an object,
id
is automatically null when it gets to the actual code.The function your extension code calls isn't the function in the API code. There's a layer in between which checks you're passing in usable arguments as specified in the schema.
The problem is that the extension manager is using our Thunderbird 60 compatibility schema, so it isn't checking our arguments, but it's calling the Thunderbird 68 implementation, so the call throws an exception. Anyway, that's easily worked around on our end, now we know what the problem is.
Description
•