Yes.

As additional security layer, security conscious web admin uses Apache build-in Authentication directives to protect CRM web pages. Authentication directives are configured in <Directory> section of the virtual host configuration (httpd.conf) file or .htaccess file in the web root directory. When AuthType Basic setting is activated on the CRM web root directory, opening the CRM portal requires username and password as shown in the following figure.

When such protected CRM portal URL is enter into to Yathit mobile app, the app will automatically ask to enter user name and password. After that the app will confirm supported version of the SugarCRM/SuiteCRM and prompts CRM username and password as follows:

Manual import/export between SugarCRM and Phone Contact book is available since version 3.0+.

Automatic sync between Phone and CRM is not planned.

This feature is available since Android Yathit mobile app version 4.0+. The feature is not available in iOS due to limitation in provided platform API.

We are process of implementing rating limiting for these cases. Estimated time lien is 2-3 weeks.

We are still investigating the issue.

I could see this is useful. To get into more detail, what information in the meeting record? How is user interaction flow will look like?

While in Contact Detail view, tap hamburger menu and then select 'Check in a meeting'. After meeting, user click 'Check out meeting'

Name: Meet with ContactName Description: Assigned User: App user Location: Address in current location Start date: Check-in time Duration: Check out - Check-in Related Contact: Contact, if Contact has Account, also relate with it.

Also see TapCRM Manual Page 30 Checkin Checkout

Do you mean audio recording during the meeting?

Please send email to sale@yathit.com to receive invoice.

In the future, you will be able to download and also receive via email.

Please send email to sale@yathit.com to receive invoice.

In the future, you will be able to download and also receive via email.

The login button in the extension is, in fact, login URL to Yathit web site. It is same as here, if you click Login in this forum.

Sorry for the late reply. After the 30 days trial expired, full feature license will automically be activated. Inserting license key is not required.

Yes, Yathit User Portal Sugar is not correctly shown license at the moment.

Please send support request to sale@yathit.com for immediate respond.

SuiteCRM is fully supported. If you have any problem, please let us known.

Without announcement, Gmail no longer show unpopular People Widget in the right side column. Hence so, Yathit Chrome Extension contact widget, which is usually under People Widget, is now shown as a new info tab, ⓘ, where you can find social network information.

Please also enable Social Info option in setting panel.

Yathit use Sugar Metadata for available fields in the module, labels, relationships, access right, etc to display panel. These metadata are rarely change and hence Yathit cache the data for long. Sugar metadata can be update immediately in the Sugar setting panel.

Thanks for the report.

We have talked about security on Yathit Blog before. This time, we want to talk about extension developers’ design choices, discuss trade-offs between security and ease of use and implementation costs. Chrome Extensions are very powerful tools and this kind of power comes with responsibility that falls on both the developers and the users. The user of Chrome extensions have the final say which extensions to be used, considering its usefulness and permissions.

Web sites are generally safe by design. You can browse any Web page, follow the links by clicking on them, even copy URL’s into your browser, etc. Web sites cannot harm your machine or device unless you specifically allow them to do so. Web sites conform to a Single Origin Policy or SOP, which means that one web site cannot interfere with other sites. In other words, the SOP states that codes such as JavaScript, which run a web page, may not interact with any resource not originating from the same site. This security policy exists to prevent malicious coders from creating pages that steal users' information or otherwise compromise their security.

However, Chrome extensions are very different and they can interfere with Web sites if given permission. Like most Android apps, Chrome extensions tends to request more permission than that they actually need. Do not misunderstand – lots of us, both developers and users love working with these extensions. They allow customization of Chrome experience and improve overall Web browsing. Problems arise when users forget about these extensions and leave unnecessary permissions on. These permissions range from accessing the browsing data and physical location to “All Web Site Data” permissions. This “All Web Site Data” permission is the most dangerous off all!

The “All Web Site Data” permission usually comes up during installation and you have only one chance to decide whether to select it or not. See the image below showing the request “All Your Data on the Web Sites you Visit”. If you select this option, the extension may be able to read, analyze and make changes on your behalf. In the same time, a perfectly legitimate extension may fall victim to an attack by unscrupulous hackers and become a malicious threat. As a result, a simple hack can gain “super powers” and take control of Web sites you visit.

Potentially, the now malicious extension can do anything on your behalf such as getting a password to a web site you use, including your financial institutions’ sites, health information and more. The extension may be able to go as far as getting your security token or cookie and transmit it to the attacker, who may be able to exploit this vulnerability to authenticate as yourself without a two-factor authentication. In many cases, these infected extensions have less nefarious goals and could be directed to violate your privacy by gathering information about your browsing habits, clickstreaming data in order to sell it to a third party, inject Ads or simply click them on your behalf.

These are the reasons why we, Yathit developers’ team, are working very hard to avoid requesting “All Web site Data Permission”. A Chrome extension like ours does not need to access all your web site data. We do not need information concerning your banking, restaurant reservations or online shopping. We only request permissions, which are required for proper functioning of Yathit extension, such as Gmail page and attachments. This is all the permissions we ask for during installation. We also ask for a permission to access your SugarCRM portal, but we ask for it only when a Sugar user accesses the portal.

Despite looking simple, this function requires an elaborate background communication between Yathit and Chrome to curry user intent while requesting host permission request. Even after the user is granted such permission, it does not become permanent, unlike the permissions granted during installation. It takes an exceptional understanding of Chrome extensions, high-level implementation skills and security expertise to keep the permission active and prevent the extension from repeatedly asking for the permission. This is one of the reasons why many developers do not want to bother with individual permissions and try to get away with a blanket “all web site data” permission request. We also need to remember that optional permissions are fairy new functions and some browsers such as Firefox and Edge still do not support them.

We would like to note that creators of extensions are responsible and ethical professionals. However, some extensions may have security issues, which could potentially be exploited by hackers. They can take over an extension and direct it against the users. During a recent Defcon Conference, a team of security researchers demonstrated this type of security breach in a speech titled “Game of Chromes: Owning the Web with Zombie Chrome Extensions”. The presentation talks about a series of events, which unfolded on April 16, 2016 when Wix servers were attacked by an army of bots, creating new accounts and publishing a number of shady sites. The attack was executed by a malicious Chrome extension installed on tens of thousands of devices, simultaneously sending HTTP requests. This extension bot used Wix websites platform and Facebook messaging service to distribute itself. The same perpetrators attacked again two months later. This time they used infectious notifications popping up on Facebook, which led to a malicious JSE file. Upon clicking, the file installed a Chrome extension on the victim’s browser and the extension spread again through Facebook messaging.

We, the Yathit team, take cyber security extremely seriously. Security cannot by just talk and awareness – a concrete action is necessary to minimize threats and protect our users as well as the product. The developer’s responsibility is to assure security. As users, we must choose wisely.

Could you elaborate what do you want to do?

If you are referring to make log call from your Android Phone, current it cannot. You will have to use Desktop Chrome browser to log a call.

Sugar mobile app is in the plan, but it is likely to be a year away.