I am using MailKit to retrive emails from a Gmail account. However, I have been confused about the Id of an email.
I already looked at the documentation but could not find a complete explanation.
For example, I noticed UniqueId, is actually not unique; I mean if I move an email to a particular folder and fetch that email it has an Id (say 1). Then if I remove that email from the folder and add it again to the folder it gets andother UniqueId (e.g., 2)!
When I try to get MessageSummaryItems.Id the value for my emails are null.
The value for MessageSummaryItems.GMailMessageId is a big number that I don't know if it is realy uniquely assigned to that email.
The value for MessageSummaryItems.Envelope.MessageId seems a globally unique Id for that email.
I want more explanation about these Ids?
GMail does not support the OBJECTID extension, so MessageSummaryItems.Id will never get anything (e.g. the returned IMessageSummary.Id will always be null).
MessageSummaryItems.Envelope.MessageId is the Message-Id header value.
MessageSummaryItems.GMailMessageId is a GMail-specific identifier that is similar to the UniqueId but is globally unique for your account.
A UniqueId is a unique identifier, but is folder-specific. In other words, a message with a UniqueId of 5 in your INBOX folder will be different from the message with a UniqueId of 5 in your Starred folder, for example.
However, on GMail, a message in your INBOX with a GMailMessageId of 5 will be identical to a message in your Starred folder with the same GMailMessageId. They will both refer to the exact same message.
To understand why this is, GMail really only has 1 folder (All Mail) where all of your messages are located. All of your other folders, including INBOX, Drafts, Sent, etc. are just virtual views of the All Mail folder that filter out all messages that do not have the corresponding GMail Label.
That's why if you add a label to a group of messages, they will show up in your INBOX and in a new folder that gets created that matches the name of the label that you just created.
Related
I have sugarCRM 6.5.20 OnDemand. I am in the Studio. I have a 1:1 relationship from Leads to Leads. I am trying to get the Primary Email address of the related Lead and display it in a calculated field.
It seems like the calculated field formula should look like:
related($emails,"email1")
When I do that I get the following error:
Invalid formula: related: Unknown Field : email1
The dropdown list doesn't list the email at all. How can I get the email? All of my web searches have proven ineffective.
Update:
I am willing to make the calculated field be the primary email address of the current lead. To do that I found 2 variables named $email_addresses and $email_addresses_primary and $emails. There is also a function called valueAt.
I tried to use valueAt(1,$emails) and valueAt(1,$email_addresses)
The validator accepted the syntax but the value was always empty.
Can I make a calculated field off of the leads primary email?
You won't get the Email field for the Studio's formula calculation. Email field is stored in a separate table and not in the module's table. It is just put in the Layout along with the other fields of the module, but it is not the same as other fields. All the Email Addresses irrespective of the modules are stored together in the email_addresses table and are related to respective module records in the email_addr_bean_rel.
Is there any Key or name field (in Message.Header or else) SAME or RELATE for both received and sent mail .
For example, MessageId is unique key for each message. But I want something else (Key).
I had not found any field in Message.Header(Message or MimeMessage or with also MimeMessageHelper)
I am using Java.Mail and I want to group each received and reply mail with a key.
Anybody help me, Please ?
In a word.
No.
There is nothing in the headers to tie one email to another. The closest you can do, is compare subjects + the Date.
Given that an ABRecordID can change between cloud syncs and under other circumstances out of my control, how can I maintain a long-term reference to an IOS address book record?
Apple provides the following guidance:
"The recommended way to keep a long-term reference to a particular record is to store the first and last name, or a hash of the first and last name, in addition to the identifier. When you look up a record by ID, compare the record’s name to your stored name. If they don’t match, use the stored name to find the record, and store the new ID for the record."
But I don't understand this guidance. If the address book can have duplicate names in it AND since users can modify the name in a record how could this advice work?
For example, if the user modifies the name of an address book record my routine will fail to find it by ABRecordID so if I think search by the name hash I stored couldn't I find a duplicate name instead of the new ABRecordID for that specific record I previously referenced?
In the end, what is the BEST way to get a long-term reference to an IOS AddressBook record? And if the above advice really does work what am I missing?
The most robust (yet not completely failsafe) approach would be to come up with a priority ranking of ABRecord fields and store as much from that list as is available, along with the ABRecordID, into your own (hashed) private record format. When retrieving a private record (or at another convenient time), you can verify that the private record matches the ABRecord and work through a series of fallback checks to ensure it's accurate.
Example priority ranking:
ABRecordID
FirstName
LastName
PhoneNumber
ZipCode
When retrieving a record you can first match the ABRecordID. If that returns no results, you can do a search for FirstName + LastName. You can then match those results against PhoneNumber... etc. In this way you could potentially distinguish between 2 Bob Smiths, as they may have different phone numbers (or one may not have a phone number). Of course, depending on how long your priority list is, the more robust this mechanism will be.
The last resort would be prompting the user to distinguish between 2 Bob Smiths with brand new ABRecordID's whose records are otherwise identical -- after all, such an inconvenient prompt would be far more friendly than allowing the User to contact the wrong Bob Smith (and as I said, would be a last resort).
This solution for AB may involve some synchronization issues, however.
This is a familiar problem for anyone who has worked with the iOS Media Player. Specifically MPMediaItems in the User's Music Library have a property MPMediaItemPropertyPersistentID which the docs describe as:
The value is not guaranteed to persist across a sync/unsync/sync cycle.
In other words, the PersistentID is not guaranteed to be persistent. Solutions for this include doing similar fallback checks on MediaItem properties.
The RecordID only get changed either on delete or reset, when this is done all the new record(s) will have new createdProperty and modifiedProperty as well.
While I am reading the address book for the first time, I will save all entries of the record along with RecordID in my database.
I will save the last time the contacts synced from contacts to my database(name it something: lastSyncedTime) and store it some where.
I am done with syncing the contacts for the first time, now do the following for syncing anytime in future.
while Iterating through all records,
check createdTime(kABPersonCreationDateProperty) vs lastSyncedTime. If createdTime > lastSyncedTime, store the recordID in a "newRecords" NSArray.
If !(step 1) then check modifiedDate(kABPersonModificationDateProperty) vs lastSyncedTime. If modifiedDate > lastSyncedTime, then store the recordID in a "modifiedRecords" NSArray.
if !(1) && !(2) store all recordID in a "unModifiedRecords".
Now I will read all the contacts from my local database,
I will delete all local database records that are not find either in "modifiedRecords" or in "unModifiedRecords".
I will update all "modifiedRecords" in the local database.
I will create new records for all records in "newRecords".
Update the lastSyncedTime accordingly.
The documentation is communicating to you that you can't count on ABRecordID as a permanent identifier.
Consider this scenario: The user has a record for "Bob Smith". The user then deletes his "Bob Smith" record and then imports his contacts from his computer (creating a new ID) through iTunes sync.
So if you want to keep a permanent reference to an existing contact, you can keep a reference to the name and id as a hint that it is the same record you used before- but there is no real permanent reference.
If you keep a permanent reference to an address book contact, you must always be ready to deal with the fact that it may not be the same contact you used before.
Refer :
https://developer.apple.com/library/ios/documentation/ContactData/Conceptual/AddressBookProgrammingGuideforiPhone/Chapters/DirectInteraction.html#//apple_ref/doc/uid/TP40007744-CH6-SW2
Clearly tells you how to handle it.
I'm working on Ms Dynamics Crm 2011 development and I encountered following problem.
My situation:
I want to be able to automatically send an Email after a change on a specific status field on a record of the Entity "MyEntity". "MyEntity" has an Email-field. I try to create a workflow which sends an Email to the Email-field address of the "MyEntity" record after the status has been changed. My problem is that I can't add in the Email Creation workflow to the "To" field this "MyEntity" Email-field adress. I need to somehow specify in the workflow to dynamically add the "To" field, the relating Email address from the specific "MyEntity". Is that possible? Is there a workaround for that? It could be done with a plugin I guess, but by now I'm trying to avoid the plugin solution.
Thanks in advance
John
Yes, you should be able to. First go to Solutions, bring up your entity, go to Fields, bring up your e-mail field and ensure the Format is e-mail. Publish.
Work around: If you have more than 1 e-mail Format text field, change the others temporarily (to text from e-mail) and Publish. Otherwise, the next step is ambiguous and we don't have control over which field CRM sets up as the email to use when this entity is used for e-mail.
In the solution frame, select your entity node in the tree. Under Communication and Collaboration, check the box 'Sending e-mail (If an e-mail field does not exist, one will be created).' Save/Publish.
Fix the work around above if you had more than 1 e-mail format text field. Change them back to e-mail. Publish.
In Workflow, select your To Field. Under the Send e-mail step, select 'Set Properties.' Select the 'To' field. In the form assistant you should not be able to select your entity. NOTE: You will bind to the 'Key' field and NOT to the particular e-mail field.
This only works for a single e-mail field on your custom entity. There is no way to use a text field as an address in a CRM 'to' field.
Unfortunately you cannot.
Out of the box the To field in an email accepts only
Account
Contact
Facility/Equipment
Lead
Queue
User
So in order to achieve the goal , you will have to write a custom workflow activity (optional : taking the custom text field in your input parameter )and refer it in your workflow or develop a plug-in.
Sample code for Plugin:
SendEmailRequest req = new SendEmailRequest();
req.EmailId = emailId;//ID of created mail
req.TrackingToken = "";
req.IssueSend = true;
For more information check this post Crm 2011 :Workflow - Sending email problem
In many of my apps, it requires associating some data with a contact in addressbook. What I used to do is save the record id of an ABPerson and use that id to pull information upon each app launch. However, more and more I find that this approach is wrong because many times a user will use a service like mobileme where the addressbook is wiped and resynced. This causes the record id to change and all associations are lost. The user will have to go through each one and re-link them.
What is a better approach to holding a robust pointer to addressbook entries?
You should store three values: the record ID, the first name, and the last name.
1) In the case that the record ID hasn't changed, you're golden - just use that to locate the proper record.
2) If ABAddressBookGetPersonWithRecordID() does not locate a record for your stored record ID (it returns NULL), then you'll need to search the person records for a match based on the first and last name. You can drop down to using ABAddressBookCopyPeopleWithName() potentially or write your own locating code if you already have an array with all the person records in-memory. Locating the new record is up to you. Once to locate the new record, you can update your data storage with the new record ID.
Ultimately, you end up storing the record ID to use directly incase it doesn't change (if you're lucky) plus storing some keys from the address book entry that are unlikely to change. The name of the person or organization associated with an address book entry is most likely to change. You should, of course, account for the case where you may not find a record with the stored record ID or by searching for the name. This could trivially mean that the record was deleted, or it could mean that the record was renamed. You should handle that case whichever way you decide is best for your specific application.
I know this was last year, however, I thought I might suggest a method I use. The first time I ask the user to pick a contact (in order to associate certain of my app's private data with it) I then grab the record, create my own internal record id (the initials of the app name and a sequence number usually) modify the contact by adding a new ABRelatedName (type of "pref" name of "Other") value of my own internal record id. It looks like this in the .vcf
item3.X-ABRELATEDNAMES;type=pref:BZA101
item3.X-ABLabel:_$!<Other>!$_
That way, I can simply reference that record id when i add more data about the user such as the last time the app user contacted them, etc. Seems to work for me.
Hope that helps someone.
If the address book is indeed being completely wiped and re-loaded, and the only part that doesn't change is the display name, then storing the display name as the link seems like the only option.