abushyk

Одно и тоже. Имеется в виду некоторое поле со справочными значениями и вариантами значений (обычно это select_by_query). Типа как встроенный район или город.

Зарегистрированым пользователям ничего отсылаться не будет. У них есть ЛК где легко и просто можно увидеть все свои объявления и их состояние. Для незарегистрированого пользователя ЛК нет, а пытаться угадать адрес-ссылку своего объявления, что бы увидеть доступно оно или нет, ему будет сложно. Именно поэтому и существует уведомление.

Да, все, что я написал про айдишки и их вставку. нужно принять к сведению, но не более. Я сейчас с утра пересчитал разряды в числах в скрине и понял, что обсчитался - там не миллиарды, а всего лишь миллионы.

ИД объявления является его ключем. Ключ хранится в специальном поле с размерность целого числа. Т.е. максимальное значение в этом поле может быть 8 миллиардов. Вы втыкиваете туда числа после этой границы. Естественно они не влазят. Отсюда и ошибка. Но это только начало. Поле ключа не просто хранилище, а автоикрементное хранилище. Вложив туда значение база данных сдвигает внутренний счетчик на одну позицию вперед, что бы обеспечить невозможность дублирования ключей. В итоге вы передаете в БД число большее допустимого, оно превращается в максимально допустимое и вставляется. Все остальные идешки передаваемые вами тоже больше допустимого и тоже приводятся к максимальному допустимому. Но так как такой ключ уже занят первым объявлением, то вставить последующие уже нельзя. А так как счетчик ключей УЖЕ сдвинулся к верхней границе (в момент когда вы вставили первую запись с максимально возможным значением), то больше ничего нельзя добавить в таблицу объявлений от слова совершенно. (хотя тут вру. ниже границы максимума можно, но только явно указывая свободную идешку. А вот с формы добавленяи объявы или с админики уже не добавится) Нельзя рассматривать идешку объявления в БД, как аналог артикульного номера. Это абсолютно неверный подход. Если нужно хранить артикульный, то нужно хранить его в нормальном текстовом поле. Потому они и называются непечатными. Как минимум не пользоваться контролЦ-контролВ. Но єто в общем. Если можете, зашлите мне на почту (abushyk собака gmail.com) файл, я посмотрю.

Админка - Настройки - Общее ищите параметр Не очищать таблицу загрузок автоматически (dontclean_uploadify_table) Если ее поставить в 1, то она будет сохранять загруженные картинки при ошибках на форме. Но при этом есть минусы. При достаточно криворуких пользователях замусорится папка кеш и таблица загрузок - нужно будет периодически делать чистку. При достаточно активных и криворуких пользователях могут быть артефактные картинки, оставшиеся от предыдущего добавления, но не добавленные, например когда юзер загрузил фотки, но передумал.

99% что это у вас там непечатные символы между названиями фоток, которые не видно в экселе, наставлены.

Я так понимаю вы пытаетесь загрузить объявления со своими ид?

Сообщение о публикации объявления уходит только на почту указанную в данных объявления - "Ваш email" (системное имя email). Даже если объявление приписано к какому-то пользователю, но в поле email объявления будет указан адрес, уведомление пойдет только на последний адрес.

Во первых, это делает не мейлбокс. Во вторых, наличие кнопок от мейлбокса в карточке просмотра не влияет на отправку уведомления.

/template/frontend/realia/realty_view.tpl ищем строки {if $smarty.session.user_id!=$user_data.user_id.value && $mailbox_on==1} {include file=$apps_mailbox_block title_data=[$data.topic_id.value_string,$data.city_id.value_string,$data.street_id.value_string] to=$user_data.user_id.value message_to_author_title=''}{/if}узнаем ид пользователя к которому у нас прикрепляются объявления гостей. Обычно это пользователь _unregistered. Допустим его ид = 4. Тогда в найденных строках первую из них меняем на {if $smarty.session.user_id!=$user_data.user_id.value && $mailbox_on==1 && $data_shared.user_id.value!=4}

Какой у вас шаблон?

Если в модели объявления есть поля fio, email и phone они всегда должны выводиться в первую очередь (если они заполнены), даже поверх данных пользователя, к котором прикреплено объявление. Кроме случаев, когда эти поля закрыты правилами видимости для групп пользователей. ПС. Но тут могут быть отклонения в зависимости от исполнения шаблона, хотя стандартно все так, как я описал. Мейлбокс не будет отправлять на сторонние почты. У него задача создать внутренне сообщение и уведомить об этом пользователя сайта.

$news_list_column[i].img_preview_srcзамените в этом файле на $news_list_column[i].img_preview

В том и секрет, что движок ни слухом, ни нюхом о том является ли поле основным или нет. Он внаглую берет знакомое поле и использует его. Всю выпадающую логику из этого алгоритма нужно реализовывать программно.

Добавлением колонки тут не обойдешься. Одна колонка - одно поле. Тут нужно ваять локальный выгрузчик, в котором переправлять функцию exLocation что бы она брала данные не из привычного поля, а и нужного. И вот тогда уже добавлять колонку.

Это и есть флешзагрузчик. Его можно переключит на более адекватный настройкой, что я писал на pluploader. А то, что вы видели - это уже другой тип поля. На него нужно мигрировать.

Исходно стандартным как раз является флеш-загрузчик. Настройки - Общее - Тип загрузчика и селект на uploadify\pluploader (первый - флеш, второй - хтмл). Но это имеет значение только для полей uploadify_image. Для поля типа uploads флеш вообще не применяется. Но обычно флешзагрзчик и есть самым глючным, в ФФ, априори он убит. А у вас какой сечас загрузчик? Как выглядит?

Пока нет. Сейчас мы пробуем вариант организации информеров для внешних сайтов. Если все будет ок, тогда будем прикидывать как организовать работу формы.

Скорее всего поле cian_export не прописалось в БД. Зайдите в редактор форм и в блоке модели data есть кнопка Обновить таблицу. Нажмите ее, она пройдется по полям и проверить их наличие в физической таблице и, если не найдет, добавит.

Заявки те, которые /getrent или /client/order/... или те, что клиентские, но через аякс?

Если разделы вашего сайта содержат в каком либо виде указание на тип контракта (аренда, продажа, сдам, посуточно... в любом виде) и у вас нет в модели поля Тип операции (optype) - то 99,9% что зашит))) Открываете Админка - Приложения - Редактор форм. Разворачиваете модель data и смотрите поля. Обычно по названию поля (Обая площадь, Площадь участка...) можно примерно понять, что оно олицетворяет на форме и, аналогично, в данных. Перепровериться можно через форму добавления в админке меняя в форме Тип недвижимости, что бы учесть установленные права видимости. И я не помню ссылку на ваш сайт.

В общем тут получается немного не так. Карта выводится в режиме classic. Но этот режим - исключение из режимов главной страницы. По сути это не главная, а просто первая страница списка, в отличии от slider|search|carousel. Из этого следует, что если мы вынесем спецпредложения вверх карты, а следовательно и вверх списка, то они будут маячить там всегда. Но тут можно сиграть иначе. Поскольку это у нас по сути сетка, то за ее вывод отвечает /template/frontend/realia/layout_full.tpl а в нем за вывод самих спецпредложений строка {include file="top_special.tpl"}Вы можете найти ее почти в самом низу. Отличие в этом случае "главной" от неглавной страницы состоит в том, что главная - это когда икакие параметры не запрошены - адресная строка браузера содержит только домен. Поэтому строку {include file="top_special.tpl"} в том месте где она стоит, заменяем на {if $REQUESTURIPATH !== '' } {include file="top_special.tpl"} {/if}и в этом же файле, сразу после<div id="main">добавляем {if $REQUESTURIPATH == '' } {include file="top_special.tpl"} {/if}Иными словами, если запрашиваемый адрес у нас похож на "главную" мы выводим спецы вверху и не выводим внизу. А если не похож, то наоборот.

"Страна по умолчанию " - текстовое название страны в которой размещены выгружаемые объявления. Важно для тех случаев, когда у вас в модели не фигурирует страна как признак. Например вся география у вас начинается с города и дальше район-улицы. Поле:Значение отвечающие за признак продажи Поле:Значение отвечающие за признак аренды Поля для установки признака как определить тип сделки. В таблице ассоциаций практически каждый АФИ-тип представлен в двух ипостасях: - Тип (Общее) - для моделей где Структура не отражает тип контракта и он указывается отдельным полем, напр. optype - Тип (Продажа\Аренда) = для тех моделей у кого нет отдельного типа полд операцию, а Аренда єто или продажа можно определить то иерархии пунктов Структуры. Если у вас тип контракта зашит в Структуру, то вам нужно использовать второй вариант установки ассоциаций и нет смысла указывать упомянутых два настроечных поля. Если первый способ, то в этих полях нужно указать поле и значение элемента которое будет соответствовать определенному типу операции. У меня Тип операции - это поле optype типа селектбокс со значениями 1-Аренда и 2-Продажа. Тогда я указываю optype:2 и optype:1 соответственно. "Регион по умолчанию, например, Московская область" - аналогично стране, только для региона. Код валюты по умолчанию, например, RUR/EUR Для моновалютных сайтов. Можно указать дефолтную валюту и даже не заводить поле под Валюту в модели объявления. Системное имя общей площади для квартир и комнат Системное имя общей площади для нежилой Системное имя общей площади для домов Системное имя общей площади для участков Группа настроек имеющий общий смысл - указать в каком поле модели искать значение общей площади. Изначально в модели существует поле Общая площадь (square_all). Оно ничего не означает - чистая условность. Там может быть и общая площадь квартиры, и общая площадь участка или дома. Но обычно модель дополняется. Например под участок заводится поле square_lot в котором держат площадь участка , а поле square_all гасят для этого типа недвижимости. Все это ведет к тому, что существуют разные и непредсказуемые названия полей и алгоритм нахождения нужного становится нереальным. Для этого добавлены упомянутые настройки. Если вы четко знаете, что в square_all у вас лежит площадь квартир, в square_total - для коммерческой, в house_ploshad - площадь для дома и в square_lot - площадь участков, то просто пропишите эти поля каждое в своей настройке. Тогда выгрузчик не будет искать знакомые ему поля или что-то выдумывать, а возьмет значения из указанных в настройках. Например дойдя до участка, он будет искать поле и значение square_lot , а не как описано в алгоритме искать lot_area, а когда не найдет его, то проверит square_all , а так как там тоже пусто - выдаст ошибку.

Админка - Настройки - Выгрузка AFY Тут можно указать системные имена полей из вашей модели, которые соотвествуют данным по площади. Например для квартир у вас общая площадь в square_all, а для участков площадь участка в landarea, т.е. каждый тип имеет свое поле. Вот их и нужно было бы указать в настройках. А если для всех объектов у вас общая площадь хранится в одном поле, тогда не надо было бы.

Ну да, скрин потерялся. Но раздел настроек приложения вы уже должны знать)) Указали вы поле для участков "Системное имя общей площади для участков" которое содержит общую площадь для участка? Если нет, тогда общая площадь будет браться из полей по уразумению движка, а такие поля могу не существовать в вашей модели, либо иметь иной смысл. Невыгружаемые записи - они точно участки? Не в смысле в Категории на сайте, а в ассоциациях устанавливаемых в таблице ассоциаций приложения. Так как выгрузчик не "понимает", что в разделе Участки у вас лежат именно участки.