Realtor

Доступно обновление system 2.9.0
 
ВАЖНО! Новая версия работает с PHP 5.3 и выше. Поэтому перед обновлением включите на хостинге новую версию PHP.
 
1. Создание API для работы с мобильным приложением https://play.google.com/store/apps/details?id=ru.sitebill.mobilecms
2. Также включены следующие изменения
- обновление способа хранения языковых переменных шаблона  доступа к ним из кода - на форму add добавлена возможность назначать текст перед формой - realtymap возвращена возможность устанавливать иной от штатного маркер по-умолчанию - для эементов типа select_by_query добавлена возможность навески кастомных onchange через параметр onchange - Добавлены настроечные параметры групп для зарегистрированных и автозарегистрированных пользователей. - Конфиг параметр для сортироваки по дефолту в сетке объявлений. - мелкие оптимизационно косметические правки. Упорядочивание видимых элементов при регистрации и правке профиля владельцем. Добавлены опустимые для выбора группы в форму регистрации. - Перемещена функция пользовательских операций в realty_view выше по дереву вызовов. - Изменено поведение элемента формы типа date. В поле value возвращено чистое значение из БД в виде таймштампа, а приведенное (форматированное) перемещено в value_string - Добавлена обработка параметра минимального количества изображений на поле uploads (без яскрипт обработчика) - Добавлен постобработчик для регистрации с возможность дополнить операциями действия после регистрации пользователя. - Вывод в админке фильтровок по Биллингу - В менеджер пользователей добавлена обработка поля uploads - в get_user_model() добавлена возможность указывать какую модель получить - с обрезкой по правам видимости групп или полную. - Ликвидировано "зависание" картинок-аватаров пользователя, когда при сохранеии новой аватарки страя физически оставалась в папке картинок. - add - поправлено получение значения авторегистрированного пользователя. При переходе а DBC была пропущена получение ид юзера.
- Добавлена возможность выбора для модели User выбирать ли ее с правами видимости или нет и связанные с этим правки + мелочи в грид_менеджере

Стараемся этого особо не практиковать так как, когда есть пользователи личных кабинетов, страшно замусоривается база.
 
Потому, что для того, что бы они появились в списке их нужно дернуть из БД. страна, регион, город, район, микрорайон, улица, дом - каждый раз, все из БД. много лишней нагрузки.
 
 
Это-то возможно, но в рамках конкретного проекта. Для базовой версии - тут больше мороки будет, чем профита.
 
Создается один объект с нужными данными и множится кнопкой Дублировать в списке объявлений в админке.

Интересно, поизучаю эту фишку.

Это можно. Но как это относится к доверенному gmail.com?

А какой доверенный адрес? Он в @gmail.com?

Присвоение группы в регистрации
if(0!=(int)$this->getConfigValue('newuser_registration_groupid')){ $form_data[$this->table_name]['group_id']['value'] = (int)$this->getConfigValue('newuser_registration_groupid'); }else{ $form_data[$this->table_name]['group_id']['value'] = $this->getGroupIdByName('realtor'); } Если есть в настройках значение для newuser_registration_groupid, тогда вносим пользователя в нее.
Если нет, тогда берем идентификатор группы realtor.

Что бы все нормально посмотреть в какой-то стране, надо минимум три раза туда съездить!)

В будущих версиях возможно сделаем.
А сейчас пока браузер открыт хранится.

Сто процентов пропустишь!
Даже если прочитаешь самый подробный путеводитель, будет повод вернуться.

В настройках приложений
 
Заявка на аренду
 
добавить поле email по которому будет пересылыться поданная заявка, в этом случае сотрудники агентства не будут ждать когда админ соизволит скачать и переслать данные заявки. В аренде играет быстрота принятия решений
 
 
Почтовый ящик
 
В настройках добавить отправлять сообщение на email
При отправке пользователю на его email указанный в профиле будет приходить сообщение
Вам пришло сообщение в Личный кабинет на ....

Экспорт объявлений в pdf 
 
В настройках сделать возможность брендирования, т.е.подключения header и footer для идентифицирования - в header шапку в виде картинке логотипа, в footer картинку в виде контактов
 
Избранное и выборка по поиску с главной - возможность сформированную таблицу   раcпечатать в pdf или отправить по email
А также чтобы объявления из таблицы  были с активными ссылками
 
 
Рассылка объявлений недвижимости
 
В настройках добавить отправлять сообщение на email Клиенту
В таблице данного приложения будут добавлены поля Имя клиента, телефон и email
И при выполнении условий поиска, будет приходить сформированная ссылка, не только в ЛК агента  Клиента которого он ведет, но и самому Клиенту.
Т.е. это приложение можно будет использовать как клиентскую базу, с так называемыми отчетами агента, что он предложил клиенту, пока он его вел.
 

Фотки из Флоренции (родина Данте и гнездо Медичи)
https://plus.google.com/u/0/photos/+DmitriyKondin/albums/6050669108204201057

Фотки из Венеции - самое большое впечатление в Италии я получил именно от Венеции.
https://plus.google.com/photos/111879861141150728306/albums/6053591431327547377

$query = "update ".DB_PREFIX."_data set active=1 where rent_end >= '$now_day_minus_5' and rent_end <= '$now_day'"; Примерно такой запрос.

Такая ошибка возникает, когда в данных (описание, площадь, цена и др.) используются специальные символы.
Например м2
Скажите точный адрес выгрузки, посмотрю строчку с этой ошибкой.

Добавить в базу таблицу черный список телефонов. 
При добавлении объявления через ссылку на сайте добавить объявление или через загрузку exel файла или при загрузке xml файла, будет происходить сравнение номера телефона подающего объявление с черным списком. В случае совпадения объявление с таким телефоном не будет активироваться и попадать в архив с определенной пометкой.
Механизм поиска по номерам телефонов уже есть в админке.

В ЛК разделить таблицу объявлений на Все Активные Архив (неактивные) Корзина 
с возможностью оптовой Активации, Деактивации, Удаления и Восстановления

Нужно конкретное решение или просто алгоритм-методика?

решение, с описанием функций и вариантами смарти-шаблонов. Я думаю, будет популярным среди пользователей системы

Продолжаю отдельными постами, так как исчерпал лимит на картинки в одном сообщении ))
 
4.1. Секции.
 
Не буду давать расширенного описания, скажу только, что все идентично как для корпусов.
Таблица csection и поля csection_id, name, ckorps_id (по таблице ckorps)
В принципе для секций можно было бы установить двойную зависимость - указывать принадлежность секции к корпусу и к ЖК. Для некоторых случаев это оправдано (особенено если делается полноценное приложение), но в нашем случае, когда необходимо лишь поразграничивать принадлежности и сам корпус и ЖК будет указан в свойствах недвижимости, такая связка будет избыточной.
 
В итоге
  5. Внедрение в недвижимость   Сущности у нас готовы, можно приступать к привязке их на объявление.   Нам необходимо добавить три свойства в нашу таблицу data - ЖК, Корпус и Секция. Все они будут добавляться полями типа select_by_query, что бы мы могли сформировать их списки в элементах выбора из соответствующих таблиц. Носить имена будут эти элементы czhilcom_id, ckorps_id и csection_id   Если теперь мы перейдем в форму добавления объявления мы увидим, что наши новые три поля уютно прописались в форме в виде привычных списков выбора.   Но если их поразворачивать, то вы увидите, что они вмещают все варианты из своих таблиц и не реагируют на состояние "родительского" элемента. Например выбор ЖК никак не отражается на содержимом списка корпусов.   Приступаем к наладке связей.   6. Связывание   Основой для связывания служит принцип связанных элементов формы - http://wiki.sitebill.ru/index.php?title=%D0%A1%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D1%8B   Нам необходимо в рамках одной формы указать элементам на какие другие элементы они влияют в форме и от каких зависят.   Например - ЖК. От состояния этого элемента зависит возможный список выбора в элементе Корпуса. Эта зависимость описывается как Это значит, что элемент, в котором мы выбираем название ЖК связан с элементом с системным именем ckorps_id (элемент выбора Корпуса ЖК), а ключем, который внутри Корпуса соответствует жилому корпусу является значение из поля czhilcom_id модели Корпуса. Если взлянете выше, то это значение в модели Корпуса у нас является идентификатором ЖК,  к которому привязан Корпус. Больше ЖК у нас ни на что не влияет, потому и других параметров нет.   Далее Корпус. Корпус, аналогично ЖК влияет на "следующий" элемент - Секцию. Но, кроме этого, он еще должен знать от какого элемента зависит сам - это необходимо для формирования адекватного списка значений элемента Корпус, но не тогда, когда сделан выбор конкретного ЖК, а при загрузке формы. Например, если вы открыли на редактирование объявление в котором ЖК был указан как Элитный, тогда в списке Корпусов вполне ожидаемо окажется уже готовый список корпусо ЖК Элитный.   linked - описывает зависмость когда элемент влияет на что-то. depended - когда что-то влияет на элемент   И, наконец, Секция. Самый простой элемент. Он ни на что не влияет, но на него влияет Корпус. Что и видно из параметров.   Нет ничего страшного, если вы ничего не поняли про связи с первого раза. Это нормально, Я гарантирую это.   Если теперь вы попробуете загрузить форму добавления объявления, вы видите, что у вас доступен на выбор только элемент ЖК, а остальные будут подгружены только после выбора соответствующего родительского.   Для того, что бы увидеть этот эффект в Настройках необходимо включить параметр Настройки - Дополнительно - Off system Ajax   7. Эпилог   Ай, у меня не работают элементы выбора географии. Что делать?...   Тут все ожидаемо. Изначально принцип связанных элементов предназначался как-раз для географических элементов, что бы вывести из кода движка жесткие зависимости Страна-Регион-Город-Район\Улица и иметь более широкую возможность настройки своих связей. А так же, иметь возможность введения промежуточных элементов (Страна-Регион-Субрегион-Город), которые разрывали бы существующие связи, заложенные в код Сайтбилля. Именно поэтому опция Off system Ajax отрубает всю систему заложенных связей.   Возможно это слишком кардинально и стоило бы предусмотреть ступенчатую систему, когда подключение пользовательских связанных элементов регулировалось бы одной настройкой, а отключение привычной связки от Страны к Улице другой. На данный момент четкого мнения у меня пока нет.   Для себя я решил эту проблему навеской связей на географические элементы в виде, аналогичном системным правилам.   Т.е. country_id linked    region_id,country_id   region_id linked    city_id,region_id depended    country_id   city_id linked    street_id,city_id;district_id,city_id depended    region_id   district_id linked    mkrn_id,district_id depended    city_id   street_id depended    city_id   mkrn_id depended    district_id   8. Offtop   С другой стороны, даже этот способ немного избыточен. Если Город является дочерним к Региону, а Регион к Стране, то хранение всех трех значений для объявления - это "лишние" данные, хотя при организации поиска они весьма кстати.   Суть в том, что географические данные вполне возможно хранить в виде, схожем со структурой
  и получать к ним доступ более "человечным" путем Но в этом случае остается так же много вопросов связанных с совместимостью с многими приложениями, принципом организации смой геоструктуры (ведь если заструктурить географию от страны до улиц - это может стать неподъемным грузом, а если закончить городом, то не совсем понятно, как вести связь дальше к улицам, которые должны таки быть привязаны к городам или чему-то наследному от них).   В общем идея у нас полно, была бы возможность все реализовать)

1. Предистория
 
Допустим мы имеем базовый сайт на сайтбилле. У нас есть стандартная модель квартиры-недвижимости со всякими Цена, Площадь и прочими свойствами по вкусу. И вот, в один прекрасный момент, мы решили заняться торговлей квартирами в новостройках. А новостройки эти у нас зачастую представлены не отдельными зданиями, а целыми комплексами зданий, которые в свою очередь разбиты на секции.
 
2. Анализ.
 
Сначала разберемся со структурой. Самый простой вариант - мы решили еализовывать каждую квартиру в виде отдельного объекта. Например, если в ЖК "Элитный" у нас есть корпус А, а в нем секция I и в этой секции, грубо говоря, 15 квартир одной планировки, но некоторые на разных этажах, мы будем считать, что каждая квартира, даже одинаковой планировки - является одним объектом. Иными словами, мы не делаем группировок по типам, а ведем каждую квартиру отдельно. Это дает нам некоторую гибкость, так как квартиры на крайних этажах могут иметь меньшую цену в отличии от одноплановых с ними, на остальных этажах. Так же, из плюсов то, что мы можем задать какие-то особенности поквартирно, даже не смотря на то, что они одноплановые. Особенно это касается, когда квартиры продаются не в сыром виде, а меблированные или с финишной отделкой. Либо учесть иные особенности каждой квартиры.
 
Из минусов такого подхода то, что если секция у нас 9-ти этажная с 4 квартирами на этаж, то на секцию получается 36 объектов. И дальше в геометрической прогрессии в зависимости от количества секций в корпусе и корпусов в ЖК.
 
Соответственно, логично предположить, что кроме обычных для недвижимости параметров (цена, площадь, этаж,и т.д.) нам придется снабдить модель недвижимости дополнительными параметрами, устанавливающими ее привязку к конкретному положению в разрезе ЖК - конкретный ЖК, корпус ЖК, секция корпуса ЖК. И так же очевидно, что при заполнении формы эти параметры должны бы быть связаны цепочкой, как то при выборе отдельного ЖК, мы должны получить под выбор список корпусов только этого ЖК, что бы не рыскать в длиннющем списке всех корпусов. Аналогино и с секциями.
 
3. Инструментарий.
 
Для реализации нам понадобятся свежие приложения system, admin, table, customentity. Привлекать готовые приложения типа "Жилые комплексы" мы не будем.
 
Из настроек нам будет необходимо включить параметр Настройки - Дополнительно - Off system Ajax. Данная опция выключает автоматические связки между зависимыми элементами и предоставляет нам полный контроль над определением своих зависимостей.
 
Из почитать - http://wiki.sitebill.ru/index.php?title=%D0%A1%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D1%8B
 
4. Подготовка дополнительных сущностей.
 
Если мы должны иметь возможность выбрать корпус, ЖК и секцию, значит у нас где-то должны быть списки этих значений. В Сайтбилле, для организации списков значений существует два типа полей - select_box и selectbox_by_query.
 
Первый нам не подходит, так как не поддерживает организацию наследия. Т.е. штатными средствами этого элемента мы можем задать набор его вариантов значений, но не можем указать какие-то связующие ключи с другим элементом.
 
Второй, поскольку хранится в БД в виде отдельной таблицы, вполне на это способен. Но для его использования необходима соответствующая таблица в БД. В нашем случае таблиц будет три - таблица ЖК, таблица корпусов и секций корпусов. Что бы избавить себя от рутинной работы по наполнению этих данных через phpMyAdmin создадим соответствующие таблицы в Редакторе форм.
 
4.1. Жилые комплексы.
 
Для ЖК - это таблица czhilkom с полями czhilcom_id (primary_key) и name (safe_string).

Создав таблицу и наполнив ее элементами, нажимаем кнопку Создать таблицу.

Теперь таблица ЖК существует физически в БД.
Надо наполнить ее какими-то жилыми комплексами.
Для того, что бы получить доступ к работе с этой сущность через стандартную админку, воспользуемся приложением Пользовательские сущности. Для начала проверим, что приложение установлено. Для этого в админке переходим по адресу 
/admin/index.php?action=customentity&do=install
 
При переходе по нему, в случае отсутствия необходимых таблиц для работы приложения, они будут созданы.
После этого возвращаемся в Редактор форм и в заголовке таблицы czhilkom ищем кнопку со завездочкой

Эта кнопка отвечает за создание мини-обработчика для сущности, у которой нет штатного обработчика (в виде встроенного модуля или стандартного\стороннего приложения). NB. Попытка создать этой кнопкой обработчик для встроенных сущностей, как Город, Район или для тех у которых есть приложения - Баннеры, Новости - ни к чему не приведет.
 
После нажатия кнопки Создания обработчика мы увидим следующее окно

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

Если перейти по предложенной ссылке, вы получите минималистический инструмент для управления вашими ЖК где вы можете добавить ЖК в список, изменить существующий или удалить ненужный. Приложение не следит за целостностью, т.е. если вы удаляете ЖК, то об удалении соответствующих зависимых корпусов и секций вам так же придется позаботиться самому.
 
Не надейтесь на возможность реализации таким способом каких-то "творческих вывихов" - это исключительно инструмент для обеспечения удобства. Для полноценной работы с такими сущностями, как разделение их по пользователям с возможностью редактирования последними, организация страницы, например конкретного ЖК, шаблонизация необходимо создавать полноценное приложение.
 
Для наших целей добавим два ЖК - Элитный и Морской с помощью кнопки Добавить запись
Процесс, как вы можете заметить, вполне привычный и не должен вызвать трудностей
 
4.1. Корпуса.
 
Создание таблицы корпусов абсолютно ничем не отличается от создания таблицы ЖК кроме того, что у корпусов есть зависимость от ЖК. Например ЖК Элитный имеет два корпуса - Корпус А и Корпус Б. Тогда модель корпуса (ckorps) будет состоять из полей

Поле czhilcom_id является обычным полем селектбокса подбирающим данныеиз внешней таблицы, в данном случае из таблицы czhilcom
Простыня под спойлером
 
Дальше все по алгоритму - создали таблицу в Редакторе форм, наполнили полями, создали физическую таблицу, зарегистрировали обработчик. Из Пользовательских переходим в Корпуса  добавляем

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

1. Исправлена уязвимость XSS для полей safe_string. Больше нет возможности в строковых полях ввода вводить разметку.
 
2. Для поля textarea добавлена опция разрешающая все теги. (Достигается установкой параметра allow_htmltags и значения для него 1 в разделе Параметры для выбранного элемента. По умолчанию, с этого обновления, из поля типа textarea - тех, которые отображаются стандартным html-полем ввода текста - вся разметка будет вырезаться). Не касается поле с типом textarea_editor, снабженных полноценными редакторами.
NB. Обратите на это внимание те, кто использует приложение Баннеры.
 
3. В конфиге добавлены опции
Уведомлять администратора о платежах по email (notify_about_payment) При использовании базового модуля оплаты через Робокассу устанавливает необходимость отправки уведомления администратору о наличии платежа. Закрыть сайт (is_underconstruction) Закрывает фронтальную часть сайта на обслуживание. Так как опция новая, то, для полноценной ее работы, необходимы некоторые изменения в шаблоне. IP разрешенный для доступа в закрытом режиме (is_underconstruction_allowed_ip) Указывает IP адрес пользователя, который может иметь доступ к сайту, закрытому на обслуживание. Описание всех опций конфига тут http://wiki.sitebill.ru/index.php?title=%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B8
4. Добавлена автоматическая установка системных утилит
 
5. Добавлено приложение apps.logger http://wiki.sitebill.ru/index.php?title=System_logger
 
6. Добавлено приложение apps.customentity для управления пользовательскими элементами, которые нужны, но для которых нет фабричного приложения.
Для работы этого приложения необходимо сделать операцию установки перейдя в админке по адресу 
/admin/index.php?action=customentity&do=install
В ответ вы не увидите ничего, но в БД должна появиться таблица re_customentity.
 
6а. Вводится в стадию бета концепция Связанных элементов http://wiki.sitebill.ru/index.php?title=%D0%A1%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D1%8B , которая будет связана с элементами из предыдущего пункта и не только.
 
7. Добавлено приложение toolbox (для миграции картинок из старого uploadify -> uploads) http://wiki.sitebill.ru/index.php?title=%D0%9F%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5_%22Toolbox%22.
Приложение рассчитано на понимающего, что делает, пользователя и не обладает интуитивным интерфейсом. Если сомневаетесь - лучше не тыкайте по кнопкам, а проконсультируйтесь со мной (abushyk). Бекапы БД и файлов сайта, перед использованием этого приложения, обязательны.
 
8. Исправлен баг - при удалении всех категорий выскакивала ошибка.
 
9. Теперь при включении опции use_new_realty_grid видна минимальная сетка для объявлений, раньше было пусто. Остальные поля добавлять также через редактор форм - Grid manager.
 
10. Для поля uploads теперь максимальный размер загружаемого фото = установленному системой. Максимальный размер устанавливается автоматически из настроек сервера. Если сервер у вас пропускает 200М, то для картинок этот размер весьма избыточен. Дабы не дать врагам замусорить сервак стомегапиксельными картинками каждый элемент uploads поддерживает свою автономную настройку пропускной способности в виде параметра max_file_size и значения для него в виде целого числа допустимых мегабайтов на картинку.
 
10а. uploads так же поддерживают свои размеры картинок (размеры для полноэкранки и превью) с помощю параметров prev_width, prev_height, norm_width, norm_height и указанными пиксельными размерами. Єти настройки перекрывают базовые. Так же поддерживается настройка в виде параметра preview_smart_resizing, которая аналогична настройке из Настройки - Дополнительно - Использовать умную подгонку превьюшек, но в отличии от нее, работает не только на картинках для объявлений.
 
11. Создание пользовательских форм заявок http://wiki.sitebill.ru/index.php?title=%D0%9A%D0%B0%D0%BA_%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D1%82%D1%8C_%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D1%83%D1%8E_%D1%84%D0%BE%D1%80%D0%BC%D1%83_%D0%B7%D0%B0%D1%8F%D0%B2%D0%BA%D0%B8

Потому что завтра, после вас, эту тему прочитает еще кто-то.

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

Куда вставлять( после чего, перед чем)?

В ЛК разделить таблицу объявлений на Все Активные Архив (неактивные) Корзина 
с возможностью оптовой Активации, Деактивации, Удаления и Восстановления