0.00
23 читателя, 50 топиков

Дизайнер Отчетов OpenOffice в OpenERP

Перевод оригинальной статьи

Дизайнер Отчетов в Openoffice — плагин, используемый, чтобы создать отчеты для OpenERP. Его — легко установить и использовать. Главное преимущество этого плагина состоит в том, что любой легко может создавать и изменять отчеты для OpenERP.

Процесс установки

Установите используя менеджера дополнений в Openoffice.org Writer

Вы найдете 'менеджера дополнений ' под вкладкой 'Инструменты' в Openoffice.org Writer. Здесь Вы можете добавить 'openerp_report_designer.zip' файл. После добавления файла, перезапустите Openoffice.org Writer и OpenERP Report Designer меню OpenERP в Панеле инструментов будут доступны.
Читать дальше →

Планировщик в OpenERP

Перевод оригинальной статьи

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

В OpenERP Вы можете найти планировщиков в

«Установки>Настройки>Планировщик>Планировщик Действий».

Планировщик принадлежит openerp модели «ir.cron». Вот, как мы определяем планировщика в xml (рисунок 1.1)
Читать дальше →

OpenERP+Asterisk (Часть 3) Получите имя вызывающего абонента на входящих телефонных звонках (click2dial)

Статья в процессе редакции


Оригинал статьи

OpenERP+Asterisk коннектор




Получите имя вызывающего абонента на входящих телефонных звонках


Техническое введение

Вот сценарий, который объясняет, как работает функция:

1. На поступающих телефонных звонках Asterisk dialplan выполняет AGI get_cid_name_timeout.sh.

2. get_cid_name_timeout.sh скрипт вызавает get_cid_name.py скрипт с коротким перерывом.

3. get_cid_name.py скрипт обращается с просьбой XML-RPC (или XML-RPC по SSL) на сервере OpenERP, чтобы попытаться найти имя человека, соответствующего номеру телефона представленный вызывающим абонентом.

4. Если он находит имя в OpenERP, имя используется в качестве названия CallerID вызова, так, чтобы пользователи могли видеть имя на экране их IP телефона.
Читать дальше →

OpenERP+Asterisk (Часть 2) Как переформатировать номера телефонов (click2dial)

Статья в процессе редакции


Оригинал статьи

OpenERP+Asterisk коннектор




Как переформатировать номера телефонов


Эта диаграмма объясняет, как номерами телефона управляет asterisk_click2dial модуль.
В диаграмме эти два примера (ex1, ex2 и ex3) основаны на следующей конфигурации:

— Приставка: 0

— Национальная приставка: 0

— Международная приставка: 00

— Моя приставка страны: 33

Читать дальше →

OpenERP+Asterisk (Часть 1) Коннектор OpenERP- Asterisk (click2dial)

Статья в процессе редакции


Оригинал статьи

OpenERP+Asterisk коннектор




Введение

Asterisk — программное обеспечение OpenSource для телефонии. Это программное обеспечение используется, чтобы управлять IP системами в PBX компаниях, объединенных с IP телефоном для каждого служащего и трубками SIP на xDSL или традиционные ISDN линии, чтобы получить доступ к общественной телефонной сети. Asterisk доступна в соответствии с GNU General Public Licence и отредактирована американской компанией Digium. Если Вы хотите знать больше о Asterisk, пожалуйста, прочитайте ее Wikipedia страницу.

Описание коннектора

У коннектора OpenERP- Asterisk есть три главных функции.

Первая, добавляет кнопку набора в представлении адреса партнера так, чтобы Ваши пользователи могли непосредственно набрать номер телефона через Asterisk. Эта функция обычно известна как click2dial. Вот, как это работает:
Читать дальше →

Что легко, а что сложно в OpenERP (в плане разработок)

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

Рано или поздно каждый с этим сталкивается. Ведь не даром же на сегодняшний день существует более 2000 модулей. На самом деле около 50% процентов этих модулей это добавка всего лишь нескольких полей к существующим модулям. Это то что каждый из вас сможет сделать за несколько минут (технически) :).

И так что просто:
Читать дальше →

Заметка о переводе - первая (технические средства)

Общим местом является использование юникода и системы gettext. В модулях OpenERP каждый модуль имеет подкаталог i18n (это сокращение для довольно длинного internationalization — по количеству букв — I18n). В этом каталоге располагается файл-шаблон эталона перевода с расширением .pot и национальные файлы с расширениями .po. Файл .pot создаётся отдельно после написания всех программ и подпрограмм модуля, вбирает в себя все строки программ подлежащие переводу и имеет не плоскую структуру. Это хорошо видно при его просмотре с помощью простого текстового редактора. Здесь и автор перевода и комментарии по каждой строке и возможные варианты перевода для числительных и…

По большому счёту система gettext является националистической, поскольку предоставляет преимущества в скорости работы исключительно английскому языку. В случае других языков идёт поиск и подстановка, что естественно замедляет работу программ при большом объёме текстового вывода.

Я помню первые варианты интернационализации паскаля: там сообщение в программе кодировалось в цифре — номер программы, номер подпрограммы, номер сообщения. Для возможности правки, сообщения нумеровались с интервалом в десятки и сотни. Далее для каждого языка были плоские таблицы и все национальные языки были равноправны в скорости работы. Можно было создать единственный файл с ключами и переводами по довольно большим проектам.

Однако главное-то в том, что все строки перевода привязаны по месту в программах и подпрограммах модуля. В .po файле может быть несколько идентичных строк для перевода, но у них разные привязки. Из этого следует, что при обновлении в программах модуля строк кода Python (при добавлении или удалении), связи рвутся и образуются дыры в уже переведённом. Разработчики, как я понял, мало обращают внимание на это обстоятельство и обновления .pot файлов производятся только в момент новой версии.

Файлы .pot служат, как я уже сказал, шаблоном для национального файла перевода — например, ru.po

Инструмент для перевода удобнее всего, на мой взгляд, редактор poedit, он кроссплатформенный и имеется и в Linux и в Windows, хотя конечно есть и несколько других редакторов (тот же Emax). Сам .pot файл содержит только английский текст строк и пустые строки для перевода. Причём иногда строку правильнее называть позицией, потому как текст для перевода может быть весьма объёмным (например, лицензия GNU в файле для GTK клиента). Редактор poedit позволяет создать из .pot файла национальный .po файл, а также скорректировать .po файл по изменениям в .pot файле.

Из-за различной концовки текстовых строк в NIX и Windows приходится делать два варианта файлов перевода. Пакетное изменение не проходит в связи с содержанием в файлах служебной информации иногда совпадающей с символами конца строк. poedit в настройках позволяет задать вариант концовки строк.

По правилам Pythona на основе .po файлов должны автоматически создаваться транслированные (сжатые и более быстро работающие) файлы .mo, но я вижу это в единственном числе только в GTK клиенте.

Файлы .po срабатывают только однажды: при создании базы данных. Далее все переводы статически хранятся в базе данных и изменение файлов .po никак не влияет на корректировки перевода. Для коррекции нужно запускать сервер с параметром обновления или создавать новую базу.

Предлагаемая разработчиками система перевода от пользователей далеко не всегда работает по всему содержимому показываемого экрана и не может обеспечить полностью 100% перевод. Вдобавок безсистемные переводы от многих пользователей вносят сумятицу понятий в переводах.

Система Rosetta ориентирована на точечные исправления. И затрудняет действия при объёмном переводе.

Эта статья входит в цикл статей «Заметки по русификации». Все заметки:
Предлагаю заметки по русификации OpenERP
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)

Предлагаю заметки по русификации OpenERP

На основе некоторого опыта предлагаю серию своих заметок по переводу продукта на русский язык. В начальные времена Wndows перевод был коряв и более толковая работа получалась на английском. Но OpenERP никак не подходит к личному использованию, а вколачивать текущие данные и пользоваться результатами аналитики будут люди имевшие в школе по английскому 3 с — или вообще учившие немецкий или французский. Так что вопрос перевода весьма значимый.

Разработчики OpenERP весьма вольно подошли к использованию системы gettext и внесли в файлы переводов непереводимые куски динамически формируемых кодов условий и подстановок (например для массовых рассылок). Эти штуки называются доменами (областями) и заключаются в динамически, опять же, формируемые квадратные скобки.

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

Эта статья входит в цикл статей «Заметки по русификации». Все заметки:
Предлагаю заметки по русификации OpenERP
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)

Улучшенный аналог ondelete=restrict для полей many2many

По умолчанию у полей с типом many2many нет параметра ondelete, как у полей с типом many2one, который отвечает за то, что делать с элементом, который ссылается на другой элемент, если этот другой элемент удаляют.

У опции ondelete есть в таком случае два варианта:
cascade — удалять элемент при удалении родителя (не знаю как правильно назвать тот элемент, НА который ссылаются)
restrict — запрет удаления родительского элемента

Бывают случаи, когда для полей many2many тоже было бы неплохо использовать аналог опции ondelete=restrict. У меня как раз такой случай. Есть две модели — product.attribute и product.attribute.group, между которыми связь many2many.

Читать дальше →