Рейтинг: 0  
Новая
Предложил Borisenko Valentin 30.07.2019 13:28:23

HighLoad-блоки::Редактирование / удаление записей в публичной части

Реализовать редактирование элементов HighLoad-блоков в публичной части (в режиме редактирования) - аналогично IBlock:

<?
$this->AddEditAction($arItem['ID'], $arItem['EDIT_LINK'], CIBlock::GetArrayByID($arItem["IBLOCK_ID"], "ELEMENT_EDIT"));

$this->AddDeleteAction($arItem['ID'], $arItem['DELETE_LINK'], CIBlock::GetArrayByID($arItem["IBLOCK_ID"], "ELEMENT_DELETE"), array("CONFIRM" => GetMessage('CT_BNL_ELEMENT_DELETE_CONFIRM')));
?>
Рейтинг: 1  
Новая
Предложил AndreyChursin 15.07.2019 09:59:49

Добавить вывод пользовательского названия в списке HighloadBlock

На странице /bitrix/admin/highloadblock_index.php?lang=ru нет вывода наименования самих HL блоков, только их ИД и код...
Файлы:
HL.JPG (95.71 КБ)
Рейтинг: 0.0847  
На голосовании
Предложил Ульянов Владимир 17.04.2017 07:20:50

первичный ключ в hightload-блоках

Добавить возможность использовать в качестве первичного ключа не только обычный ID с автоинкриментом, а произвольное поле (например часто возникает потребность использовать ID элемента инфоблока).

Основная идея - повысить пользу от использования handlersocket (он же работает только с первичными ключами!).
Рейтинг: 2.0309  
На голосовании
Предложил Niemand 18.12.2015 14:23:49

Свойство типа "Справочник"

Сейчас в инфоблоках при привязке в качестве свойства "Справочник" уже созданного HL-блока у этого блока автоматически добавляются поля "Описание" и "Полное описание". Это крайне неудобно, их каждый раз приходится удалять вручную, так как часто свойство "Справочник" используется в качестве альтернативы пользовательскому свойству "Привязка к элементам HL-блоков", а не по "прямому" назначению. При этом поле "XML_ID", которое необходимо для работы со свойством в форме редактирования элемента, автоматически почему-то не создается. Просьба убрать автоматическое создание полей при привязке уже существующего HL-блока.
Рейтинг: 25.3435  
На голосовании
Предложил Александр 10.07.2015 08:19:35

Визуальное представление Highload-блоков в общем списке

1)
На странице (Рабочий стол/ Контент / Highload-блоки) перечислены  MySQL таблицы.

При  добавлении новой таблицы не задействовано системное поле “Комментарии к таблице”, это поле очень сильно помогает разобраться (особенно  когда количество таблиц весьма большое) зачем была создана та или иная таблица.

Прошу использовать  системное поле “Комментарии к таблице”


2)

Визуально группировать Highload-блоки по их  названиям (вернее по  префиксам таблиц)

например есть перечень таблиц:
- list_workers
- other_table1
- list_person
- other_table3
- list_report
- list_blablabla
- other_table2
....
- other_tableN

Такие таблицы  в админке хорошо бы  сгруппировать  в выпадающие  списки
“list_” ->LIST  и
“other_” ->OTHER  
так  же как это  представлено  при добавлении нового типа инфоблоков,  тогда получим :

[+] LIST:
[-]  list_workers    / комментарий к таблице (кол-во строк)
[-]  list_person     / комментарий к таблице (кол-во строк)
[-]  list_report / комментарий к таблице (кол-во строк)
[-]  list_blablabla       / комментарий к таблице (кол-во строк)
[+] OTHER  
[-] other_table1  / комментарий к таблице (кол-во строк)
[-] other_table3  / комментарий к таблице (кол-во строк)
[-] other_table2  / комментарий к таблице (кол-во строк)
[-] other_tableN / комментарий к таблице       (кол-во строк)


думаю такое визуальное представление   Highload-блоков  более наглядно для сопровождающего,  удобнее читать и ориентироваться всем)
Рейтинг: 5.0047  
На голосовании
Предложил Шкарупа Алексей 08.12.2014 23:58:06

Пользовательское свойство "Строка": указание размера и возможность его изменения

С появлением Highload-блоков и вероятности появления десятков миллионов записей в HL-блоке хочется нормального свойства типа "Строка".

Этому (нормальности) мешает:
1. Невозможность указать допустимый размер свойства "Строка"
Когда вы создаете пользовательское свойство типа "Строка" - отрабатывает класс \CUserTypeString который создает колонку в базе данных по принципу:
switch(strtolower($DB->type))
{
   case "mysql":
      return "text";
 case "oracle":
      return "varchar2(2000 char)";
 case "mssql":
      return "varchar(2000)";
} 
Т.е. даже если вы захотите хранить строку длиной 20 символов - все равно получите в разы больше.

Кроме того типовое свойство "Строка" как вы сами можете увидеть не позволит хранить более 2000 символов в Oracle и MS SQL. А ведь есть соответствующие типы.


2. Это можно было бы исправить если бы было событие OnAfterUpdate в классе CAllUserTypeEntity - но его нет. Так что даже в собственном типе свойства не получается невозможным сделать alt er   table.


Хочется обратить внимание разработчиков 1С-Битрикс на комментарий в файле /bitrix/modules/main/classes/general/usertype.php на строке 563:
* Надо сказать, что для скорейшего завершения разработки было решено пока не реализовывать такую же гибкость как в инфоблоках (обойдемся пока без alter'ов и прочего).


Может пора вернуться и доделать те самые alter-ы и прочее (события)?