Realtor

Ага. И использовать зти данные для поиска по умолчанию.

Небольшой оффтоп.
Уже сложилась практика создания структуры категорий в виде Продажа-Квартиры, Продажа-Комнаты, Аренда-Квартиры, ... Т.е объединения в одно целое различных понятий - типа недвижимости и вида операции с ней. имхо - это плохая практика. Ведь недаром стараются вести отдельно параметры жилой и общей площади. С ними тогда значительно удобнее работать, сравнивать, фильтровать, чем со значениями вада ааа/ббб.
Если все упирается в создание меню навигации в виде выпадающих списков, то затраты от разработки такого меню не есть больше минусов от содержаний структуры в виде смешанных понятий.
 
Теперь чисто теоретически.
 
Имеем таблицу re_data, re_topic, re_rubrika (объявления, типы недвижимости, рубкрики (как-то Продам, Сдам, Сниму)). Как получить сводную матрицу количеств обїявлений:
$ads_count_matrix=array();$DBC=DBC::getInstance();$query='SELECT COUNT( d.id ) AS dcount , t.name AS tname, r.name AS rnameFROM re_data dLEFT JOIN re_topic t ON d.topic_id = t.idLEFT JOIN re_rubrika r ON d.rubrika_id = r.rubrika_id WHERE d.active=1GROUP BY d.topic_id, d.rubrika_id';$stmt=$DBC->query($query);if($stmt){    while($ar=$DBC->fetch($stmt)){ $ads_count_matrix[]=$ar; }} В результате мы получаем массив вида:
[0][dcount]='10'[0][tname]='Квартиры'[0][rname]='Продам'[1][dcount]='2'[1][tname]='Комнаты'[1][rname]='Продам'[2][dcount]='1'[2][tname]='Квартиры'[2][rname]='Сдам'[3][dcount]='0'[3][tname]='Комнаты'[3][rname]='Сдам'... Дальше уже дело техники. Либо скинуть этот массив в шаблон и там его просто вывести, либо в контроллере обработать его дополнительно - упорядочить по рубрикам, типам и тогда уже скинуть в шаблон для вывода.
 
Если рубрики\категории слиты в единую структуру, то принципиально решение будет похожим, но будет больше мороки с упорядочиванием, так как надо будет вычислить какие типы в какие рубрики входят и свести их.

Вероятно наслоилось два индекса от новой и старой версии.
Главное чтобы хоть какой-то индекс присутствовал, для того чтобы не появилось две группы с одинаковым системным именем.
Т.е. оставляем только 1 индекс на поле group.system_name и не важно какой.

Никак.
При обработке данных от пользователя из ЛК
1. Поле user_id средствами цмс инициируется значением ид текущего пользователя. Т.е., что бы вы не передали с сайта, в поле юзера всегда будет указан текущий пользователь.
2. Поле user_id средствами цмс ставится в скрытое состояние. Т.е. его не видно в форме так как оно проходит hidden элементом формы. Но даже если вы его поинициируете, например, скриптом, все равно сработает пункт 1.
 
В данный момент все попытки реализовать вашу схему - бессмысленны. Так как, что бы пользователь С мог сменить владельца объявления с А на Б,ему надо получить это объявление на редактирование. Но получить объявление в ЛК, владельцем которого есть А, на редактирование можно только под логином А. Логика понятна?
Выставление видимости поля юзер_ид в модели для групп тоже ничего не даст, так как опять сработает пункт 1. Это ЛК, а не админка, доступная с фронта. Поэтому и такая своя логика.
 
Тут выходом может быть адаптация ЛК под вашу систему ролей.

Вывод цены за квметр "в лоб"
 
вычисление
{if $data.square_all.value!='' && $data.square_all.value!=0 && $data.price.value!=0 && $data.price.value!=''}    {assign var=per_meter_price value=$data.price.value/$data.square_all.value}{else}    {assign var=per_meter_price value=''}{/if} вывод
{if $per_meter_price ne ''} {$per_meter_price|number_format:2:',':' '}{/if} Это если обработку размещать в шаблоне. Поля price и sqare_all должны быть заданы в модели.