Bitrix24 як я переробляв модуль пошуку
статті про програмування
Стандартний модуль пошуку bitrix search цілком добрий, але є один недолік, якщо ви використовуєте його у вирішенні Bitrix24 корпоративний портал. Справа в тому, що результати пошуку видають особисте листування!
Отже, я почав копатися у коді цього модуля. Шляхом методу тику знайшов місце запиту. Запит не цілісний рядок, а шматки динамічного коду. Все відбувається в методі MakeSQL() класу CSearch скрипта bitrix/modules/search/classes/mysql/search.php Поля вибірки задаються в масиві $arSelect
Блок FROM та обмежувач WHERE тут
У результаті виходить наступний рядок
Проаналізувавши ситуацію, я дійшов висновку, що повідомлення з MODULE_ID = tasks, blog, forum паляться, їх треба фільтрувати. Все це робиться відсіканням та зворотним приєднанням відсіченого, вже відфільтрованого. Відсікти легко
, Та й приєднати як і те ж, за допомогою UNION. Але union має бути практично ідентичним первинному запиту, поля вибірки, їх кількість. Надійдемо хитро - замінимо аліас sc (FROM b_search_content sc), не зачепивши самі вибірки $arSelect і організатори $strSql
От і все? Блок SELECT та блок FROM готові, залишилося написати обмежувачі WHERE. Модуль tasks видає результати з особистих завдань та завдань групи, із модуля blog достатньо обмежити 'POST', 'COMMENT'.
З модуля forum — $USER->GetId() Отже, як відфільтрувати дані з модуля tasks? Вирішив відсівати по стовпцю URL. Дані там виглядають приблизно так: Особисті завдання: /company/personal/user/ 1 /tasks/task/view/1/ Завдання групи: /workgroups/group/ 5 /tasks/ task/view/6/ У індивідуальних є ВД самого поточного користувача, в групі - ВД групи. Перевіримо на відповідність $url[4] == $user_id та на приналежність до групиCSocNetGroup::CanUserReadGroup( $user_id, $group_id) Написав фу-ю temp_table($task_query) до-я створює тимчасову таблицю з ID тих записів, до-е дозволені для польз-ля. У параметрі вона отримує запит до таблиці b_search_content, де MODULE_ID = tasks. Результат запиту перевіряємо на соот-ие і значення, що збіглися, заносимо в тимчасову табл.
Досить хитро вийшло, погодьтеся.
Отже, тимчасова таблиця є, к-я містить ІД корисних записів із запиту. Склеїмо її перехресним joinом.
треба вставити до обмежувача. $strSql вже з WHERE. Ось цей трюк із заміною аліасу виявляється марним.
Тому копіюємо $strSql і вставляємо INNER JOIN, не забувши замінити аліас на su
Інші реплейси добре працюють. Нарешті фінальний запит
На цьому не усі. Запит пошуку змінюється коли я змінив систему лайків з Мені подобається на Мені подобається/Не подобається. Спрацьовує умову.
Заміна аліасів, як і раніше, працює, і навіть для завдань. Тимчасова таблиця формується дещо інакше.