4.1.1. | Does the xTuple client need to be started to synchronize Email in xTuple? Will my Email be synchronized while I'm in vacation, sick, etc.? |
Yes, xTuple needs to be running for the Synchronization to work. This is necessary because xTuple launches the synchronizer and communicates login credentials including database, user and password, so the it knows where to synchronize the data. We had originally thought about running the synchronizer as an independent service on the machine, but we subsequently decided we didn't want create potential security vulnerabilities by storing database credentials on the local machine which would be necessary to run it as a free standing service. | |
4.1.2. | if a user deletes an Email from their Email client, does that delete it from xTuple? |
It does not. | |
4.1.3. | How does the routine work to match documents? Is there a convention? |
When mail is imported into the database a trigger checks to see if a special reference is in the subject or body that has " It is important to note that just because this reference is in the subject doesn't mean it will be imported. IT IS THE USER'S RESPONSIBILITY TO CONFIGURE THEIR MAIL CLIENT AND SYNCHRONIZATION SCHEME TO ENSURE THESE MESSAGES ARE IMPORTED, because these messages are ultimately being sent by your mail client, not xTuple. The reference tagging just helps xTuple sort out the relationships IF the mail gets imported. The only messages that are guaranteed to be imported regardless of configuration are ones actually generated by xTuple Connect itself (NOT your Email client) such as Sales Order Acknowledgements, Invoices, reports to run through xTuple Connect (AKA Batch Manager processor) or any mail generated via an EDI profile. | |
4.1.4. | If two people running the sync client get the same Email, will it appear twice in xTuple? An example is if the Customer includes two participants. If so, what is the duplication identifier based on? |
They won't. Both the synchronizer and xTuple connect processors calculate a cryptographic hash on the message body that creates a unique ID that is stored with the message in the database. They compare to see if there are any messages with the same hash ID already in there before attempting to insert a new copy. If one is already found, it will skip that one. | |
4.1.5. | If an xTuple customer actually has multiple companies, a user would only be able to import into one database from a machine. Is that correct? |
That is correct. |