Добрый день!
А вот такой вопрос. Пишем самописку-отраслевку, на 8.2. Самописка не самая маленькая, но и не по типу УПП, конечно, гораздо попроще.
Есть необходимость иметь в ней модуль Администирирования (Пользователи, Роли итп).
Бегло изучила типовой функционал.
Как видится сейчас (и скорее всего - это видение истинно, так как с заказчиком, под которого это пишется, не первый год работаем) - по сравнению с типовым функционалом, будут такие различия:
1) не нужна подсистема контактной информации
2) нужны дополнительные настройки пользователей, влияющие на доступ по ролям (к какой организации и территории пользователь относится, и тому подобное)
3) Будет использоваться RLS (доступ по организациям и территориям, как минимум.)
4) Объектов в конфигурации будет довольно много, сопровождать будем тоже мы, удобство администрирования важно
5) Но ролей будет немного, будем стараться использовать правило - "одному пользователю - одну роль", чтобы избыток ролей не влиял на производительность. Как следствие - не понятно, нужны ли нам все эти громоздкие, хотя и правильные, структуры типа "Профили прав"

Попробовала интегрировать в самописку библиотеку подсистем - вроде получилось, но мама дорогая - штук 20 общих модулей и с 10-15 справочников-регистров потянуло за собой.

Вот, сижу-думаю - оно мне надо? Решила вот на мисте посоветоваться :)

Я за индустриальный подход.

Уточню, если писать самим, то видится, что обошлись бы:
справочник "Группы пользователей"
справочник "Пользователи"
пара обработок типа "Активные пользователи"
справочника или регистра сведений - "Характеристики пользователя" (закрепленная за пользователем организация, территория итп)

Т.е. вы разрабатываете не маленькую отраслевую конфигурацию, и в тоже время вас пугает 20 общих модулей и 10-15 справочников-регистров?

Зачем разрабатывать то, что уже разработано? Это про БСП.

(0) Что-то мешает превратить 20 общих модулей в 1 ?

Кому ты нужна со своими идеями?

(3) Ну, "не маленькая" - это субъективная оценка. И 20 или 30 - я точно не считала, но довольно много получилось. Чуть ли не больше, чем у нас уже разработано отраслевого функционала :)
(4) Ничего не мешает, но это точно не вариант, модули разбиты по логическому функционалу, и разбиты правильно. Вообще написано у 1С все это хорошо, как мне кажется. Просто - нам так много не нужно вроде бы :)
(5) А идеи не мои, в заголовке - это про идеи 1С :) Т.е. второй вариант - взять код 1С только частично, сильно порезав функционал.

Продавать собираешься, или про парадигму программирования?

(7) Контора продаст конкретному заказчику, с которым договор.

(7) Так что - про парадигму :)

(6) кто будет развивать твое поделие?
А БСП будет развивать 1С

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

(9) Разная она у всех, и чем дальше тем разнее. Нах "умников", но слушать надо.

(10) *отстаиваю пока вариант самописки :)*
А что там развивать будет? Два справочника? А больше и не надо будет. Мы отраслевой функционал все равно сами пишем, его что - тоже 1с будет поддерживать?
Саппортить все равно нам, а если и не нам  - то стороннему спецу не все равно ли - изучать 100 справочников или 102?

(13) Но это я так, отстаиваю вариант самописки - но решение в пользу этого варианта еще не приняла, думаю, сомневаюсь.

+

(14) Умная женщина (девушка) еще и сомневается.

(11) Но расширять БСП все равно придется, это факт,  типового функционала недостаточно.

(13) И номер хороший. Начать с УПП.

А как ее обновлять потом, кто-то уже обновлял, задействовав в своей конфе? Нормально проходит?

(18) Сорри - про УПП не поняла?

(20) Сколько конфигураций в вашей? Смотри поставки.

(20) А, не - у нас не УПП (точнее, УПП тоже есть - но это оффтопик :))
Это отраслевка с нуля, не производство. Энергетика.

(22) Переписываем код с 7.7

(23) Ты опять сама с собой говоришь. Переписываем код с 7.7. Паздравляю. Уволить нах.

(17) дык это само собой. просто в БСП есть много полезного для своей нетленки

(6) Как это, "правильно разбиты по логическому функционалу" ?  Если относится к ролям, то пусть все будет в общем модуле "роли". Это в БСП разные модули, у вас то не БСП внедряется.

(24) Обидеться, что-ли? Нет, не буду, не люблю я это дело... :)
(22) было к (21), конечно. А (23) - уточнение к (22)
Я ваших слов вообще не поняла, про УПП. Она-то тут причем? У нас УПП нет, я производство не разрабатываю.
И чем вас не устраивает  то, что мы переводим заказчика с сильно устаревшей отраслевой конфы нашей же разработки на 7.7 на 8.2, под новые требования?

(26) А там же разбито на "Модуль строковых функций", "Модуль пользователи на сервере", "Модуль пользователи на клиенте" итп. Нормально разбито. Кое-что можно объединить, но тогда обновиться уже гораздо сложнее будет, и одна из выгод БСП теряется.

(27) Это же не ЗУП, чтобы в чистом виде использовать.

Обновляться через объединение конф ?  Ну-ну.

(27) Уже лучше. В конфигурации может жить не одна конфигурация поставщика, объяснять долго. Простите, если непонятно, обратитесь  к документации.

(28) Ну, тогда это ближе к 3 варианту :) Использовать БСП, но изменить ее код.
Вариант 1 в голосовании - это использовать без изменений, только с доработками.
Я в общем-то уже по варианту 3 и пошла, честно говоря. Вырезала "Контактную информацию" и "Внешних пользователей".
Но остановилась и раздумываю - и насчет обновлений, и насчет того, стоит ли так резать типовой код, и насчет того, стоит ли вообще его брать. Поэтому и собираю мнения (они сегодня на редкость единодушны).
(30) А, это и так понятно. Я не поняла только к чему это вы говорили. У нас-то вообще не типовая была бы. Один поставщик - мы. Плюс, возможно  (как раз обсуждается в 0) - БСП.

(29) Кто запретил, назовите недостатки (достоинства) при разных вариантах.

(31) Беря себе чужой код, вы тоже рискуете, если его можно понять (локализовать, ограничить) и он вас устраивает - вперед. Все. Ключевое слово на мой взгляд - понять,изучить. Но правда этим давно не утруждаются, а скока "велосипедов" изобретено.

(33) Да там вроде бы код несложный и понятный, просто и лишнее, естественно, есть. Вообще, мне близка концепция 8.2 УФ по сравнению с той же 7.7 - я с ней вожусь около месяца всего, но почти все, кроме некоторых деталей, интуитивно понятно. Разбиение на модули, разделение на клиент и сервер, код на запросах, динамические списки итп - все довольно очевидно, поэтому типовой код легко читается. Так что я бы не сказала, что с типовым кодом сложно работать программисту - я сомневаюсь именно с точки зрения пользователя (т.е. смущает наличие "лишних" сущностей).

Ок, раз большинство за - буду продолжать работу с БСП, уговорили :)

(32) Прежде всего, нарушается основное правило в IT : "Работает - не трожь" :)))
Вот когда меня пнут пользователи снизу - это одно, это понятно. Когда меня пинает поставщик сверху - он мне как-то не объясняет своих намерений. И самое главное - заявки от пользователей уже не могут быть эффективно мной отработаны по причине зависимости от поставщика.

(34) Только 7.7 не переписывай. И книжек много хороших по рефакторингу.

(35) Жди.

(36) Упаси боже как в 7.7 переписывать  - я же не идиотка :) Мы код с нуля пишем. Да и все равно там и требования предметки очень сильно поменялись, и старая система устарела.

(38) Это правильно, это хорошо. Главное, чтобы деньги платили, и чтоб не побили после, поэтому делать надо хорошо, а то жаловаться придешь "Я нетленку неписал, а она не нужна". Успехов!

Кстати, а кто в курсе насчет лицензий на БСП? Я не поняла официальный текст.
С использованием кода нашим заказчиком все просто - если у нашего заказчика есть подписка на ИТС и конфы от 1с (есть и УПП, и Зарплата и Бухгалтерия), то использование легально.
Но что насчет нас? Мы сторонняя контора, разработчики, но без статуса франча. Подписки на ИТС нет.

(40) Т.е. можем ли мы использовать БСП без подписки на ИТС, при условии, что у нашего заказчика она есть?

Велосипед лучше купить, а не изобретать.

(41) Прикинь, у 1С сайт тоже есть. Там модно спросить. www.1c.ru они там не сразу кусаются.

Сударь, вы язва! :) Я их боюсь, а вдруг таки укусят? :)

(44) Спасибо, сударыня. А я так хотел сделать что - нибудь хорошее.:(

(45) А, ну тогда спасибочки, конечно! :)
Точно не укусят? Ну тогда так уж и быть пойду спрошу их. :)

(46) Я вас не видел и за других отвечать не могу:) Может и укусил бы...

Ну вот, решила написать резюме после внедрения БСП, может пригодится для таких же как я.
Все с БСП нормально, на самом деле. Это я сначала не разобралась, невнимательно доку с ИТС читала. Можно ровно под мои пожелания ее настроить, если в точности следовать инструкции. Вырезать профили и контактную информацию согласно штатной инструкции, а не как я делала сначала, методом тыка.
И если ставить по инструкции, а не как я сначала ставила ("сначала сделай, потом читай инструкцию" :) ), то гораздо меньше справочников и модулей тянет.

(48) с чем Вас и поздравлямс )

Тоже писали, для энергетики нетленку) писали без БСП. Так уж они сверху решили. Хотя я бы использовал БСП, но ктож станет слушать простого разработчика.

автор лжет

интеграциия подсистемы пользователей без контактов, физ.лиц и подсистемы ПраваДоступа лобавило всего два регистра в мою конфу "ВерсииПодсистем" и "СоставыГруппПользователей".

Видимо она потянула и подситему "ПраваДоступа" с этими самими профилами, хотя пишет, что они у них Свои.

я проигнорил эту подсистему и сваял свой простой регистр Прав. вот и и все. А сама подситема пользователи меня устараивает.

Общие модули да втянула около 10, но большая часть их полезна.

(0) бгыыыыы


испугалась количества модулей - ну напиши тогда свое...
в чем проблема?

положи все в один модуль...
как в 7ке было - в глобальный в один.. на сто миллионов строк....

(51) Ну прямо лгу. Ошибаюсь, правильнее сказать. Да, именно потянула лишнее, невнимательно читала доку :)
Сейчас почти все устраивает, хотя кое-что лишнее все же есть.
(52) Я не люблю и не знаю стандартную 7.7, потому там у меня всегда был 1cpp и классы, а не общий модуль. Меня не количество модулей смущала, а их ненужность, которую тем не менее пришлось бы поддерживать, отсматривать код и все такое. Вот,все равно ведь пришлось тянуть ненужное "Обновление информационной базы" и левые роли типа "ЧтениеБазовойНСИ". Но это уже не смертельно. Потом выпилю, наверное. А может и так оставлю.

(0) Тоже думали, когда свое писать начинали. В итоге пришли к выводу, что 1С молодцы, много за нас уже сделали. А "лишнее" всегда можно функциональными опциями скрыть.

не надо изобретать велосипеды

(53) чем мешают ненужные модули? ведь они загружаются только по мере использования

(52) Ты вот прямо таки третий Камин описал...

Если хочешь сделать что-то хорошо - сделай это сам(с).

лучшее враг хорошего

1С разработало огромный универсальный танк, обвешанный ракетами, ковшами, антеннами и пр. пр.
Если вам надо выкопать яму и вы захотите снять с танка экскаваторный ковш - вам придется вместе с ним снимать и переставлять себе гусеницы  и башню. потому что ковш приварен к ходовой, на ходовой - гусеницы и башня. Оно вам надо?

Ну вот, только я успокоилась было, обрадовалась: БСП взлетела, много объектов за собой не тащит, работает.
Начала использовать реально, начались проблемы.

В частности, в справочнике Пользователи в форме элемента в событии ПередЗаписьюНаСервере создается пользователь ИБ. Так как, как выяснилось, это не транзакционное событие, то если уже при записи пользователя происходит какая-то ошибка, то естественно, пользователь ИБ остается существовать, так как создается раньше записи "просто пользователя", а вот "просто пользователь" не записывается.

И после устранения причины ошибки, все равно пользователя не сохранить уже, так как система не дает вставить дубликат пользователя ИБ (а пытается).

Это косяк разработчиков БСП? У меня с 8.2 еще не слишком большой опыт, может я где-то не права?
Меня это начинает тревожить: насколько качественный код в БСП? На первый взгляд-то все красиво, но вот, полезло...

да уж всяко покачественнее твоего будет

(63) Ну, если моего кода было бы всего 10 строк, а их - 10000, то не факт.
В 10 строках не ошибешься, если есть хотя бы минимальное представление о программировании. А в 10000 и гуру может запутаться :)

(63) То есть понятно, что они грамотные разработчики. Но как тогда быть с проблемой из (62)? Или я таки не права, и это нормально, что они пишут пользователя ИБ в ПередЗаписью?

Скажем так: БСП я все равно уже оставляю, это факт. Вопрос формулирую так: как вы считаете, описанное мной поведение чем-то мотивировано или баг? Т.е. мне его править, или оставлять как есть, потому что потому?

(65) что-то вы какая-то наивная. Как будто платформу 1С и конфигурации, в которых десятки тысяч багов пишут неидеальные разработчики, а БСП вдруг пишут "идеальные" разработчики. Наверно, фирма 1С специально завезла их с планеты Юпитер, чтобы они написали идеальную программу.

(66) Перенеси в обработчик ПриЗаписиНаСервере. Протестируй. И расскажи о своих наблюдениях)

(65) ты уверена, что запись пользователя иб - это транщакционное событие?

я плохо знаю БСП. но почему-то думаю, что проще выкинуть ту же КИ и дописать своё, чем изобретать велосипеды на всё подряд.))

(69) может и нет. Но тогда там должна быть внятная ошибка при повторной записи, а сейчас там пустое сообщение. В общем, завтра буду исследовать, видимо...

Зачем разрабатывать то, что уже разработали другие?

.

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

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

Если писать свое - ета крута, но тогда вы будете похожи на одинокого верблюда в Сахаре, гордого верблюда, но обреченного.

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

(0) ох, засудит тебя Маня!

(67) Не, это уже поздно. Умерла так умерла. Выбор стоит уже между "не трогать БСП, только добавлять функционал" и "править код БСП".
(72) Не тестовый, с декабрьского ИТС. 1.2.2.3. Возможно, что и в переносе проблема, но вроде нет. Суть ошибки выявлена уже давно - попытка повторной записи пользователя ИБ после второго сохранения. Конкретнее сегодня отслежу. С отладчиком борюсь пока :)
(68) Ага, сегодня попробую все и доложусь :)
(76) Уже начала курить эту траву. Ладно, разберусь, где только наша не пропадала :) Честно говоря, я на мисту пишу больше в порядке "пообщаться, на жизнь пожаловаться" :)))))

(78) ок, я предлагаю график

- утром отчет о проделанной работе
- в обед немного истерики и легких ругательств
- пополудни восторженные вхлипы и нервный смех
- к вечеру все такое

(76) А потом после таких решений, надо курить еще более забойную траву чтобы с интегрировать решение ТС с типовой БП, или еще чем

(79) надо полагать, ты первый в очередь на "все такое"? )))

Ну вот, почти нашла конкретную причину проблемы.

В ПередЗаписьюНаСервере разработчики БСП принимают решение - создавать или не создавать нового пользователя ИБ - анализируя значение ТекущийОбъект.ИдентификаторПользователяИБ. Если оно заполнено, то считается, что пользователь есть.

После создания пользователя ИБ в ПередЗаписьюНаСервере они присваивают ТекущийОбъект.ИдентификаторПользователяИБ = НовыйИдентификатор;
рассчитывая тем самым на то, что повторно пользователь не создастся.

Но, похоже, что это присвоение не влияет на реквизит формы. И когда мы откатываем транзакцию по созданию нового "просто пользователя" в ПриЗаписиНаСервере, то мы при нажатии Записать снова вызываем ПередЗаписьюНаСервере, и похоже, что в нее снова передаются значения с реквизитов формы, то есть - пустой идентификатор. Система считает, что пользователя ИБ нет, а он есть. Вот и ошибка.
Решение, которое я вижу: исправить код БСП, добавив помимо ТекущийОбъект.ИдентификаторПользователяИБ = НовыйИдентификатор;
еще и
Объект.ИдентификаторПользователяИБ = НовыйИдентификатор; // то есть запомнить в реквизите формы
Тогда все работает :)
Т.е. ИМХО все же баг БСП.

(82) предлагаю ознакомить разработчиков БСП с данной доработкой :)

В качестве базы взять БСП, и если уже надо, только тогда на её основе развивать свое решение.

(83) А это решение тоже имеет недостатки еще пока. Я поэтому и сказала "почти нашла" решение проблемы, а не "нашла".
Так как надо еще и предусмотреть ситуацию, когда после попытки создать пользователя и ошибки, отказываются от создания пользователя. Надо либо удалять пользователя ИБ, либо еще что-то. Думаю дальше :)

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

(82) я накатил как описал выше только пользователей из БСП и никаких траблов с записью не было, наклепал пару десятков с приложения без проблем. Правда формы свои клонировал, открыл там список ролей и прочие красивости.

Вечно высосут проблемы из пальца, чего-то небось недолила при интеграции)

(87) см (86) - дело не в интеграции, баг таки там есть, просто в типовой БСП он крайне маловероятен.

(88) не совсем понятна потребность отказа записи нового пользователя :)

(86) яссно, работаем не правилам - вот и получили.

Идеология работы с посльзователями на УФ и БСП в частности такова, что нет смысла создавать пользователей(кроме системного) из конфигуратора или на лету, например при первом входе анонимуса по логин/пароль домена.

Таким образом делать какие-то автозаписи куда-то и зачем-то при записи пользователя как элемента справичника нет смысла, а нужно делать согласно привычной технолигии по команде "НастройкаПрав", "ВходимостьВГруппы" и т.д.

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

(89) Если рассматривать Пользователя как целостный бизнес-объект, включающий и ПользователяИБ, и дополнительный (мой) регистр сведений данных пользователя, то при ошибке записи какой-либо из сущностей, остальные тоже не должны создаваться.

(90) Это запись в регистр сведений с формы элемента справочника. Регистр сведений хранит дополнительную информацию о пользователе. Делать так (т.е. все в одной форме) - это ТЗ, оно не обсуждается.

(90) И, как я говорила, если будет какая-то ошибка после ПередЗаписью и в штатном БСП, то проблема будет та же. Просто вероятность такой ошибки сильно меньше, но она есть.

(92) У меня тоже есть свой подобный добавленный регистр, где простейшие измерения/ресурсы по доступу или настройке.

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

зачем ломать идеологию управляемого приложения и делать вложенные записи через одно место, а потом кричать, что БСП глючная - в угоду своим заблуждениям, непанятно)

(94) Можно скрин того, что у вас получилось? Возможно, я не в курсе какой-то возможности УФ. Форма записи в регистр - у вас отдельная форма или закладка на форме пользователей? Можно ли записать пользователя не указав свойства в регистре? (мне надо, чтобы было нельзя!)

(94) Но еще раз подчеркиваю: вложенные записи не я тут придумала. Разработчики БСП как раз "вложенно" создают пользователя ИБ. Но не обеспечивают механизма отката в случае ошибки. Так что это таки баг :)

(95)

http://dl.dropbox.com/u/7750370/mista/_598752/Пользователь.bmp

http://dl.dropbox.com/u/7750370/mista/_598752/ПользовательПрава.bmp

если сылки не рабочие, значит я не художник и не копипастер)

(95) можно конечно, зачем это ограничение и куча вариантов коллизий как у вас.

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

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

(97) А, понятно, спасибо. Так и думала. Можно попробовать, но не знаю, прокатит ли. В ТЗ работа должна вестись с одной формой, без перехода в подчиненные. Хотя... если симитировать заголовок формы такой же как в форме пользователи... может и пойдет :)

Вот мне нравится идея подчиненных форм, если бы только они ее немного улучшили, на мой вкус! В части того, чтобы она выглядела продолжением основной формы, и можно было бы легко определить, к какому объекту она относится. А то сейчас владелец виден в панели слева, но он же не влазит вообще, фиг заметишь, кто это.

(99) ничто не мешает "покласть" динамические списки регистров доступа и параметров на форму элемента справочники пользователи, но зачем делать монстроидальной одну форму?

ТЗ писали пенсионеры?)

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

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

(102) Не-не! Это как раз и есть препона: никаких кнопок! потому что операторы путаются с окнами. Справочник "Пользователи" конечно еще можно так сделать, потому что целевые операторы - по определению продвинутые юзеры.
Но остальные формы должны делаться по принципу "как можно меньше кликов, по возможности вся информация на одной форме, как можно меньше окон форм". Закладки допустимы. Панель навигации тоже, наверное - но тогда вверху подчиненной формы должны дублироваться основные реквизиты владельца, чтобы была иллюзия, что команда панели навигации - это своеобразная закладка.
Мы вынуждены конкурировать с системами не на 1С, где все это сделано гораздо удобнее в части интерфейса, и если делать не так, ссылаясь на то, что "1С так не умеет", нас же пошлют... Если там и просмотр, и ввод на одной форме. И это веб, а не что-то старое. Как тут объяснишь, что 1С - это прогрессивно?

(101) ТЗ писали ДЛЯ пенсионеров :(

(103) все правильно, для конечного пользователя так и должно быть - минимум кнопок окон, максимальная и одновременная понятная концентрация данных в формах.

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

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

(105) Чего-то пользовательский интерфейс сапа Р 3-го не отнюдь не показался мне "юзер-френдли", имхо, 1С много удобнее. Других подобных систем не имел щастья лицезреть.

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

вопрос лишь в том кто и когда будет делать тонкий запил, а не на чем)

(107) я стандарт смотрел, отразить документ движения материалов - это нада очень постараться.

(108) Не-не-не, не САП, упаси боже. Я про чисто местечковые системы, от которых конечные пользователи в восторге, а это редкость. САП - это монстр, а монстры милыми не бывают, если это не монстр из Диснеевского мультика.