Reason:
Autocompleting person contacts works as expected - ksearch_value is available and passed to triggerEvent.
But with group autocomplete, ksearch_value is reset (to null) and triggerEvent call lacks necessary data.
Explanation:
Alternative would be to leave type empty, as it is when contact comes form SQL source.
But this feels overly ambiguous and may cause problems in the future.
Reason:
In order to enable development of sophisticated autocomplete algorithms, they will need
to process all the data relevant to autocomplete - what was the search string and which
result was the correct one.
Example to illustrate the need:
Say we are talking about these two people of interest, who are in the address book, among others:
- person 1: Bostjan Skufca <bostjan@a2o.si>
- person 2: Bostjan SkuBIC <bostjan@otherdomain.com>
Our user is used to think about the first person by the first name, "Bostjan", as he is an old friend.
The second one is a colleague at work where people call themselves mostly by surnames, "Skubic" in this case.
Without this data provided to 'autocomplete_insert', there is no way for RC to learn that when our user
enters "bos" in the To: field he thinks about person #1 (Bostjan SkuFCA), and when he starts typing "sku"
he means person #2 (Bostjan SkuBIC).
Two reasons:
- provide it to plugin backend functions that use 'contacts_autocomplete_after' hook
- provide it to frontend
Why to frontend?
If plugin JS adds an 'autocomplete_insert' hook we need to provide it with exact
autocomplete data. Providing it with name and email address only, without pinpointing
exact origin of this autocomplete result, will severely limit learning capabilities of
potential future autocomplete implementations.
Reason:
Having genericly named variable $id in nested loops makes code unreadable.
Replacing generic name '$id' with '$ENTITIY_id' format removes all ambiguity.
Julian Matz