Widget Upload

Packing and uploading the archive

It is necessary for the archiver to package only the widget folder by the archiver into the zip-archive, which must necessarily be called widget.zip.

We go to Kommo in the developers section, where we received the widget code and load our archive.

If the upload is successful, you will receive an appropriate message. In the line with the code of the widget there is also the version number of the widget and the number of widgets included.

The initial status of the widget is private. This means that the widget is visible only to users of your account.

The widget can accept 4 statuses:

  • private – in this status the widget is visible only to the creator. The main status of the widget development
  • moderate – the widget is placed in this status only if the widget needs to be published for all Kommo users
  • prepublic – the status at which endpoints of widgets work. In this status, widgets are included for final testing before publication. For a long time the widget can not be in this status. (the status is exhibited by our employees)
  • public – a widget with this status is available on all Kommo accounts for installation and use. The widget enters this status after successful moderation. (the status is exhibited by our employees). In order to roll out an update of an already published widget, you need to upload an archive with a different code, and at the time of moderation specify that you need to replace the already published widget

Immediately after uploading the widget, you will be able to see it on the widget list of your account, as well as others will see it if you post the widget.

Checking the widget

For verification, you can use a simple php script.

if ($_POST ['password']=='test')
{
  $response['value']='data saved';
  $response=json_encode($response);
  echo $response;
}
else
{
  header ("HTTP/1.0 401 Unauthorized");
}

Widget Moderation

Important! The widget must match our standards

General:

  • Easy to use. A technically unprepared user should understand how to enable the widget, how to configure it, how to work with it, and
    where to get support. Than work with the widget is more understandable, the more users it will use.
  • Quality of manufacture. There should be no known errors to the developers. In the case of emergency situations, the widget should issue
    a message to the user about the failure and contact information for the reference.
  • Security
  • Encoding – all files must be encoded in UTF-8 without BOM.
  • No comments – the code should be clean.
  • The code should not be minified or obfuscated.
  • No debugging in the code.
  • There is no test data in the code.
  • The integrator should not develop software similar to Kommo systems.
  • If the widget works only on specific tariffs, this information should be in the widget’s description.
  • When using chat channels, you must specify the data of the registered channel and leave a note about the availability of the functional only to EN.
  • The folder for placing image files that are used in the widget must contain 5 files (formats png, jpeg, jpg or gif) that will be used as the widget’s logo in different scopes. The size of each file should not exceed 300 KB).
    • logo.png, logo_main.png, logo_small.png are used on the widget settings page. Sizes: logo.png 130px x 100px, logo_main.png 400px x 272px, logo_small.png 108px x 108px.
    • logo_min.png and logo_medium.png – in all lists and cards of contacts or deals in the minimized and expanded state respectively. Sizes: logo_medium.png 240px x 84px, logo_min.png 84px x 84px.

In the frontend part:

  • The widget should not modify pages that are not included in the allowed list, including the billing page
  • The widget should not pull templates from external resources, all templates should be in the archive
  • There is no alert () and console (log, debug, error, etc.).
  • There were no ajax requests in the cycles.
  • There are no unverified references to the elements of the main application (For example: var i = APP.setting.new.another).
  • If the widget uses Web sites, it is necessary that when events occur, multiple requests to the API are not sent if the widget user has multiple tabs open.
  • In the widget there should be no connection of external dependency files via document.createElement (‘script’) and inserting this element directly into head (all external dependencies must be connected via requirejs in the dependency block in define).
  • The widget should not affect the data in the global variable APP, it can only read data from there.
  • Check the widget styles. It is necessary that the widget does not break system styles and all selectors are built relative to the widget block so that widgets use statics with cdnjs.com. There should not be global selectors.
  • If the widget uses the user’s data (API key, email) there should be a notification that the data will be sent to the server of the moderated widget. In this case, the user must confirm this point. Without confirmation, the widget should not be installed.
  • The number of used localizations should be equal to the number of lang files and all the lugs must be filled correctly.
  • The widget code should not be based on switcher styles (switcher__on, switcher__off) – they are deprecated and are to be removed from the system.
  • The widget should not hide / change / replace ratings and reviews in the integration section and the modal widget settings window.

In the backend-part (if any):

  • All variables and actions must be verified.
  • A URL request must contain a timeout and better if it is executed through our class.
  • No dumps (even commented).
  • No empty methods.
  • The connection of a third-party library is discussed separately.

Only those widgets that must be published for all Kommo users are moderated. The main issues that are considered during moderation:

  • Easy to use. A technically unprepared user should understand how to enable the widget, how to configure it, how to work with it, and where to get support. Than work with the widget is more understandable, the more users it will use.
  • Quality of manufacture. There should be no known errors to the developers. In the case of emergency situations, the widget should issue a message to the user about the failure and contact information for the reference.
  • Security

How to submit a widget for moderation:

  1. Write to chats Kommo or to support@kommo.com message stating:
    • The widget code to be published
    • Widget work description
    • The instruction in which it will be specified, how to connect a widget and how to work with it
    • if required – by test data for connection to a third-party system, because Before publication, our employees will check the functionality of the widget from the user’s point of view
  2. In the description of the widget there should be a telephone and an email where the end user or our technical support person can get advice, assistance or correction of an error
  3. The widget at the time of transfer must be ready for publication, i.e. there should be no debugging, test data in the code, a description of the widget should be ready, languages should be defined for publication
Custom settings