22 марта 2013 в 4:02
Здравствуйте!
Я новичок на этом сайте и “без году неделя” как в WEB-разработке. За шесть месяцев безостановочной учебы прошел от постройки.ру через htmlbook.ру через learn.javascript.ру (спасибо Артуру и всем авторам) и сайты по основам РНР до Друпала.
Все нравится в Друпале и на этом форуме пока нахожу ответы на все нехитрые вопросы, что возникают у меня по ходу изучения системы.
Но кроме как создания сайтов-визиток разного уровня сложности и интерактивности, у меня давно была идея помочь в организации документооборота той небольшой компании, где я сейчас работаю (работаю не как IT-специалист). Точнее перевести самую важную часть документооборота в электронный вид.
А документооборот совсем не хитрый: это просто поток заказов. Покупатели заказывают в одном из наших магазинов какой-то отделочный материал и его установку, продавец заполняет форму с описание покупки и работы и эта форма уходит в другой офис, где по ней заказывается материалы и назначаются наряды установщикам, и затем эта бумажка приходит на склад.
Проблема в том, что в такой ситуации никто не видит полной картины, что происходит с заказами, на какой стадии исполнения они находятся. А для менеджеров это очень важно. Все орг работа – это бесконечный телефоно-звонит.
Что я хочу: все заказы хранятся в базе банных, которая выводится в виде таблицы, где каждый заказ – это, к примеру, одна строка. В зависимости от наличия прав, пользователь, может просматривать, дополнять, содержание заказа. Сами заказы вносятся в базу данным продавцами. Все очень просто.
Я уже написал форму-заказа, которая отправляет заказ на РНР обработчик и он закидывает его в базу, откуда эти заказы можно извлекать в том порядке и виде, каком требуется. Это уже сделано в самом простейшем виде. Но это долгая работа: писать весь код самому.
В какой-то момент возникла мысль: каждый заказ – это как страница-нода, таблица-заказов – это представление-подборка нод. У продавцов таблица отсортирована по дате покупке, для склада – таблица заказов сортируется по дате наряда-заказа для установщков. Все очень просто. Пользователь может вносить дополнения в заказ непосредственно в текст ноды или в виде комментария, в зависимости от ситуации и прав.
При этом эти “заказы” и весь докумнтоообоот не несет в себе какой-то чувствительной финансовой информации, как номера счетов, кредиток, и не подключается к какой-то банковской системе. Это просто поток описания покупок. Но там есть адреса, суммы, телефоны, поэтому всю эту информацию нужно защить так сильно, как это позволяет сделать ситуация.
В этом и вопрос:
как сделать подобный, совершенно служебный сайт, защищенным? Насколько вообще можно серьезно рассматривать Друпал в роли организатора документооборота?
У меня есть следующие идеи в плане ограничения доступа к сайту:
(1) конечно, сделать no index,no follow мэтаттег.
(2) Возможно дать сайту произволное и техническое имя как FG365hg0.com – для предотвращения случайного попадания на него (или вообще обойтись без доменного имени, извините, не знаю еще всех тонкостей IP-маршрутизации)
(3) строго запретить пользователям-сотрудникам сохранять пароль доступа на сайт в браузере(?)
(4) самому не сохранять пароль в FTP клиенте, даже если работаешь на Убунту.
Может что-то лишнее? Может что-то еще добавить?
Спасибо что дочитали до конца.
Любые ваши идеи до данной теме – very welcome here.
Комментарии
положить сайт на внутренний сервер и ходить к нему по vpn.
Почитайте о интранет-системах. Ещё что-то похожее на папирус посм. - https://papirus.net/.
А вот это бред. Ботам (исключая Y/G на инструкции наплевать), пока 403-ю не получат в лоб.
Может вам, что-то типа такого подойдет? http://drupal-7.project-management-module.org/
Система ведения проектов. Для D6 есть еще Atrium.
В приведенном списке идей два контура защиты просматриваются:
1. Защитита сервера
2. Защитита пароля на компьютере пользователя (сохранение пароля и неиспользование ФТП)
Защита на стороне сервера
1. Обычная друпал аутентификация (видимо уже используется) - достаточна для большинства целей
2. Переход на https - существенно повысит защищенность
3. Перевод сервера и всех клиентов в VPN еще более повысит защищенность
Защита на стороне клиента
1. Если все работают со стационарных компьютеров настроить на сервере фильтрацию по IP
2. Разделить права доступа к информации (если бизнес позволяет): менеджер видит только своё, видит только часть информации, с которой работает именно сейчас, а не может "слить всю базу"
3. Организовать VPN
4. Выдать всем индивидуальные USB-токены
5. Сканировать радужную оболочку глаза...
Прошу поправить и дополнить меня. Сам поддерживаю внутренний портал на друпале с информацией средней секретности. Часть из описанного реализована, часть считаю избыточным.
Огромное спасибо за ответы, много полезной информации, буду на выходных внимательно читать и разбирать, то что не понятно.
Думаю, еще будут возникать вопросы.
Такую систему на Drupal сделать вполне можно, и это вполне нормальное решение.
Для защиты, можно ограничить доступ к сайту. Если нет необходимости удалённо с ним работать - всё очень просто, сайт работает на внутреннем сервере компании, и к нему просто нет доступа извне.
Если надо иметь доступ из разных мест, например филиалов, или отдельного склада, то всё это реализуется, как выше правильно написали, расширением внутренней сети предприятия на основе VPN.
«2. Переход на https - существенно повысит защищенность»
Спасёт только от перехвата трафика, что сценарий довольно редкий, а в данном случае вообще вряд-ли кто-то его применит - информация не настолько важная...
Это совершенно лишнее, кроме того не поможет.
Сервер сайд:
1. Да, вполне, особенно если сайт во внутренней сети.
2. Мало смысла.
3. Обязательно, если это действительно интранет ресурс, ну или в простейшем случае просто рабта в рамках сети предприятия.
Клиент сайд:
На счёт радужки сложновато, а отпечаток пальца сейчас вполне доступно... И опять же для авторизации на VPN.
1. Это и так достигается работой во внутренней сети, смысла делать отдельную фильтрацию обычно нет.
2. Это в любом случае надо делать, и делается легко системой ролей Drupal.
3. Если сеть распределённая, или нужен удалённый доступ к чему-либо, это всё равно надо делать вне зависимости от наличия сайта...
4. И авторизовывать с их помощью на VPN сервере... ...вполне вариант.
5.
А ещё, должна быть политика информационной безопасности компании, смена паролей, учёт доступа к данным и.т.п., но всё это к Drupal напрямую опять же не относится.
насчет первого согласен, насчет второго - меня терзают смутные сомнения: а надо ли это делать на drupal?
спасибо за ответы.
собственно идея делать это на Друпале возникла спонтанно, и мне кажется в порядке изучения системы - это может быть совсем не плохая попытка. Моя идея перевести часть документооборота в эл вид - это моя личная инициатива. Нет сомнения, что руководству она покажется хорошей идей, но реализовать мне ее предложат без каких-либо ресурсов и без отрыва от основного производства. Смешно. Но для будущего резуме и для собсвенного проф развития: а почему бы и не сделать?
Другие варианты я не расматривал, так как пока это не приоритет, кроме того не мог (и не могу) правильно сформулировать потребность: а как называется это группа программ, которая используется для организации документооборота? Могу предположить что это исключительно коммерческие приложения с уклоном в сторону бухгалтерии (что вполне логично и правильно).
Кроме того, уже совершенно отвлекаясь от темы, у меня есть некоторое "наблюдение": если посмотреть на сайты крупных амер банков и компаний, то в адресной строке то и дело мелькают буквы ".aspх".
Я посмотрел на вики что же это такое и понял, что это целая платформа, включающая многие технилогии, и у меня такое ощущение, что у крупных компании весь документооборот построен именно на asp.net платформе. А если это так, и если ты хочешь получить мало-мальскую приличную IT работу в крупной компании, то все дороги должные вести именно к asp.net, и без вариантов (в америке). Так что у меня по плану с конца лета - изучать asp.net.
Если у вас есть какие-то мысли, комментарии, возражения, раздражения, просто информация о asp.net - пожалуйста пишите: это чрезвычайно интересно и важно для меня.
еще раз спасибо
Артиум как сборка была помощнее (значительно), но на Д7 так и не вышла
Вот тоже не уверен, что правильно ваять это все на Друпал, лучше присмотреться к готовым системам.
Вообще, чего-нибудь CRMного - документооборотного Друпалу не хватает, хотя бы под Commerce или ubercart
Судя по функционалу и по тому, куда я там влез уже, там на семерку заново все пререписывать надо. Да и требуемые для нее модули еще не все в релизах.
можно есть и сборки. но зачем оно вам шаманить с бубном??
Возьмите мегаплан, попробуйте веб версию, если понравится купите серверный вариант..
про сборки - смотреть тут http://drupal.org/project/erpal как пример
Эх как знакомо это желание, сразу взять и сделать Яндекс (у меня это была своя CMF), удачи!
В принципе есть такая штукень http://drupal.org/project/crm_core и дополнительные расширения на ее основе.
ну, в таком случае -
флаг в руки, барабан на шеюостаётся только пожелать удачида
да, это views, в нём можно раскрыть сортировку для пользователей, они сами выберут, как им удобнее отсортировать, также будет полезно сделать раскрытые фильтры - например, фильтровать заказы по периоду, менеджеру, статусу ну и т.п.
для views есть плагин, позволяющий экспортировать результат запроса в xls, топ-манагерам должно понравиться
я бы посоветовал использовать в этом случае филды: во-первых, тем самым вводимая информация формализуется, во-вторых, её можно будет использовать в тех же самых представлениях
плюс Field Permissions - можно разграничить привилегии пользователей на основании их ролей.
также, порекомендую включить редакции для нод - получится своеобразная машина времени, и в случае ошибок при заполнении заказов можно будет отмотать обратно
возможно, возникнет ситуация, когда потребуется разграничить доступ пользователям с одинаковыми ролями, например - есть несколько отделов продаж, пользователь с ролью Начальник отдела продаж может просматривать заказы только своего отдела
в таком случае может пригодиться Organic groups
что касается идеи задействовать готовую сборку - мне кажется, что в таком случае учиться будет сложнее, т.к. там присутствует лишний функционал, да и логика работы готовой сборки неочевидна,
лучше собирать функционал самостоятельно, при необходимости подглядывая в сборку, копируя оттуда решения после их переосмысления
таково моё оценочное суждение
полностью согласен с последним сообщением, так и планирую сделать.
Виды будут нескольких типов по сортировке и выборке: основной поток подвержденных заказов отсорт по времени поступления и он же отсорт по дате установки.
Сами заказ - это цепочка действий разных людей, в ноде будет представлен в виде цепочки полей ноды, где описание - это редактируемое только некоторыми одно из первых полей, за ней идет тесктовые поля или селекты "материал заказан", "материал получен на склад", "Дата установки", "Установщик". По умолчанию эти поля пустые, и по мере работы заполняются разными людьми информацией. В результате в главном Виде заказов (табличном представлении) строка каждого заказа будет как прогресс-бар заполнятся слева на право, пока не дойдет до последней ячейки "полностью оплачено". Одного короткого взляда на таблицу будет достаточно, чтобы увидеть в каком состоянии находятся заказы, где что "провисает".
также будут дополнительные Виды с выборкой по магазинам (всего три) и по статусу (преварительные или подтвержденные заказы). Каждый продавец будет иметь блочный Вид со своими продажами.
Вчера изучал Виды - очень понравилось. Все отлично продумано, выглядит как серьезный инструмент. Особенно понравилось как по Аджаксу подгружаются новые странички в блочном виде.
Хочу сделать чтобы боковые блоки Видов имели ссылку на развернутый Вид той же выборки (ч.е. фактически блок - это тизер развернутого вида). добавить ссылку вручную не проблема, но может там есть пункт в настройке блочного представления, не помню...
Гораздо более важной задача - это представить Вид заказов отфильтрованный по имени замерщика или установщика в удобном календарном представлении. Т.е. продавец договаривается с покупателям о дате и времени когда можно сделать замеры и идет в пункт меню "Замерщики", выбирает подпункт Большой Чак, кликает и видит календарную таблицу с описанием того, что запланировано у Чака на тот день. Причем время и дата расписание работы Чака берутся не из какой-то отдельной таблицы БД - это все просто отфильтрованная по имени замерщика выборка заказов с представлеными полями дата и время замера(другие не нужны в этом виде). И после устанвоки модуля Календарь и Дата в вариантах отображения Вида появился пунтк Календарь! ура, все что нужно есть. НО правда он пока не работает, пишет:
Debug:
'calendar_plugin_style: The calendar row plugin is required when using the calendar style, but it is missing.'
in calendar_plugin_style->render() (line 228 of /opt/lampp/htdocs/drupal/modules/calendar/includes/calendar_plugin_style.inc).
буду разбираться, но если кто знает - подскажи что он просит? спасибо
либо в представлении надо настроить формат вывода,
либо попробуйте переустановить модуль календаря - м.б. темплейты слетели
в понедельник доберусь до рабочего проекта, где используется календарь, тогда смогу ответить поподробнее
up - пара ссылок, м.б. пригодятся
а что случилось с drupalcamp.ru?