AiHummer
ქართული▾
შესვლაპირადი კაბინეტი
v1.1.x▾
{ }Swagger

ბიტრიქს24 პლაგინი

v1.1.x · განახლდა 2026-10-14

Bitrix24-ის დანამატი აერთებს თქვენს აგენტს Bitrix24-სთან, როგორც თანამშრომლების სწრაფი შეტყობინებების შიდა არხს. თანამშრომლები აგენტს წერს ისე, როგორც დაწერდნენ კოლეგას, ხოლო აგენტი პასუხობს Bitrix24 ჩატში.

[!WARNING] Bitrix24 აქ არის თანამშრომლებისთვის სწრაფი შეტყობინებების შიდა არხი — როგორც Telegram ან Slack სტაფისთვის. ეს არის არა კლიენტური ომნიქანალი: ღია ხაზები არ არის, არა ბილეთების რიგი და ოპერატორისთვის ესკალაციის არარსებობა. ნუ გამოიყენებთ ამ პლაგინს ფრონტენდისთვის კლიენტების მხარდაჭერის ხაზინი.

პლაგინი მუშაობს ჰოსტზე და ახდენს კომუნიკაციას გეითვეისთან მეშვეობით aihummer.connector.v1 კონტრაქტი. საბოლოო მომხმარებლის ქცევა არხზე განთავსებულია არხის გვერდზე ბიტრიქს24; ეს გვერდი ეხება თავად პლაგინს.

ქვემოთ აღწერილი მედია და საერთო OAuth მოითხოვს ხელმოწერილ Core 1.4.15-ს და ცალკე ხელმოწერილ 1.1.1 კონექტორს კატალოგში გამოქვეყნებისა და განახლების შემდეგ. დაყენებული 1.1.0 ამ შესაძლებლობების ხელმისაწვდომობას არ ადასტურებს.

ფაქტები

ხელი მნიშვნელობა
ვერსია 1.1.1
პორტი 8810
გადაწვის დრო მასპინძლისთვის ბუნებრივი

რა არის ეს

ორმხრივი ხიდი Bitrix24 ჩატსა და AiHummer-ს შორის. აგენტი ჩანს როგორც ადამიანის მსგავსი იდენტობა Bitrix24-ში — თითოეული აგენტი ავტენტიფიცირდება საკუთარი OAuth ანგარიშით, არა ბოტის საერთო ანგარიშით — ამიტომ საუბრები აღიქმება როგორც კოლეგასთან კომუნიკაცია. წვდომა შეესაბამება ორგანიზაციის ACL განყოფილებების ხის პოლიტიკას, ასე რომ, აგენტის წვდომის არე შეესაბამება თქვენს Bitrix24 სტრუქტურას.

გამოყოფილი პორტალის მომხმარებლები მიუთითეთ BITRIX24_AGENT_USER_IDS-ში, პორტალი კი BITRIX24_PORTAL-ში. დეპარტამენტების მარშრუტიზაცია ზღუდავს თანამშრომლების დაშვებას; აგენტის ანგარიში არ ცვლის დავალების ინიციატორს. არსებული არასავალდებულო ავტომატური მომზადება იყენებს BITRIX24_ADMIN_LOGIN / BITRIX24_ADMIN_PASSWORD-ს.

აღნიშნულ ვერსიებში BITRIX24_VAULT_CONNECTIONS ირჩევს არსებულ, მოქმედ, ავტონომიურ OAuth კავშირს, რომელიც ეკუთვნის მის მფლობელს. გამოიყენეთ მხარდაჭერილი ნატიური საცავის/კავშირების მართვა; იგივე ავტორიზაციის მონაცემის ID აირჩიეთ ხელსაწყოების მიბმებში. ნამდვილი მფლობელი მოქმედ კონექტორს მის სამუშაო სივრცეში არეგისტრირებს /v1/admin/connections/channel-ით, გამოყოფილი connection-token გასაღებით. აგენტის მომხმარებლის ID-ით endpoint და apiKey ჩაწერეთ საიდუმლო BITRIX24_VAULT_CONNECTIONS პარამეტრში; არ მოათავსოთ ისინი აგენტის პროფილში ან მოთხოვნებში. ტოკენებს მხოლოდ საცავი აახლებს; ხელსაწყოები ამოწმებს ინიციატორსა და გაზიარებას. იხილეთ OAuth2.

როგორ გამოიყენება ეს

  • შემომავალი: გამოკითხვა კითხულობს შეტყობინებებს. მედია ჩამოიტვირთება ბაიტებად და რეგისტრირდება /v1/inbound/media-ით; აგენტი იღებს media_id-ს და არა მხოლოდ URL-ს ან ფაილის აღწერას.
  • გამავალი: Deliver Markdown-ს BB-code-ში გარდაქმნის და ნამდვილ ბაიტებს ტვირთავს im.v2.File.upload-ით. მედიის დასტური მოითხოვს ნამდვილ FILE_ID-სა და შეტყობინების ID-ებს; ტექსტი ან ბმული ფაილის ქვითარი არ არის.

განახლებისას შეინარჩუნეთ მიწოდების მდგრადი ჟურნალი. დადასტურებული ოპერაციის გამეორება აბრუნებს წინა ქვითარს. ნაწილობრივი ან უცნობი ეფექტები ავტომატურად არ იგზავნება ხელახლა; გამეორებამდე შეამოწმეთ.

employee ─▶ Bitrix24 chat ─▶ pull poller ─▶ gateway (router · turn) ─▶ Deliver (Markdown→BB-code, idempotent) ─▶ Bitrix24

მხარდაჭერილი ფუნქციები

  • რეაქციები და @-ხსენებები.
  • წერის ინდიკატორი და პასუხები, თუ ანგარიში და პლატფორმა მხარს უჭერს im.dialog.writing-სა და REPLY_ID-ს.
  • შემომავალი სურათები, აუდიო, ხმა და ფაილები ზემოთ მოცემული ვერსიის მოთხოვნებით.
  • შეტყობინებების რედაქტირება/წაშლა მხოლოდ ძველ ინტეგრაციებშია ცალკე ბოტის იდენტობით; ჩვეულებრივი OAuth მომხმარებლებისთვის არ ცხადდება.

შეზღუდვები

[!WARNING] ინტერაქტიული კლავიატურები, ღილაკები და თემის განშტოებები მხარდაჭერილი არ არის.

შექმნილი ან მომზადებული ფაილი დადასტურებული მიწოდება არ არის. ნაწილობრივი, წარუმატებელი და უცნობი შედეგები ხილული უნდა დარჩეს.

დაყენება

დააინსტალირეთ Bitrix24 ერთ კლიკზე მარკეტფლეისიდან ადმინისტრაციული ინტერფეისის საშუალებით. ჰოსტზე ადგილობრივი დეპლოიერი ჩამოტვირთავს პლაგინს, გაუშვებს მის ინსტალაციის ნაბიჯს, შეიქმნის სანდბოქსირებულ systemd ერთეულს და დაელოდება ჯანმრთელობის შემოწმებას, სანამ მზად არ მონიშნავს — ხილვა ინსტალაცია და განახლებები. შემდეგ თქვენ უკავშირისებთ ყველა აგენტის OAuth ანგარიშს და Department-ის ხეს შესაბამისობაში ყოფნით ACL-თან.

უსაფრთხოება და შეზღუდვები

  • მხოლოდ თანამშრომლთა შიდა შეტყობინებები — არაა ომნიკანალური მომხმარებლებისთვის.
  • ადამიანის მსგავსი OAuth-საიდენტიფიკაციო თითოეული აგენტისთვის — აგენტები ჩვეულებრივი ბოტ-ანგარიშები არ არიან.
  • ACL-ის განყოფილების ხე — ითვალისწინებს თქვენს ორგანიზაციულ სტრუქტურას.
  • ადგილობრივი ჰოსტისთვის — მუშაობს systemd-ის ქვეშ, არა კონტეინერში.

სად შემდეგ?