Ну такую статью я просто обязан немножко потроллить.
Ну а – я думаю, практически все еще, помимо этого, вытаскивают магнитолу и кладут ее в бардачок или забирают с собой.
Лично я уже лет 10 не видел таких людей.
В 1С на уровне платформы реализована система прав и ролей. Мы можем управлять этими элементами, создавать новые, назначать их пользователям – это все замечательно существует.
Существует отдельное право «Администрирование приложений 1С», можно дать эту роль администратору, которому будет доступна функция, например, добавления пользователей, администрирования приложения. Но при этом он не будет иметь доступа к данным.
Существует возможность ведения лога действий через журнал регистрации.
Существует еще ограничения доступа на уровне записей, он же RLS. В обычном приложении был реалован убого, но в типовых конфигурациях на управляемом приложении превратился в мощный инструмент.
у нас нет возможности более детального разделения прав администратора на уровне функций. О чем это говорит? О том, что пользователь с полными правами в конфигурации – это царь и бог в рамках конфигурации, платформы и базы данных.
Я вас умоляю. Такое есть только в типовых. В самописных суперпользователей нет. Есть в конфигурациях Совместно" и "Совместимо", но это требование 1С. В сильно дописанных типовых тоже суперпользователей не делают. С полностью типовыми конфами работают только мелкие компании. Значит, статья на них не распространяется
Журнал изменений - просто ерунда написана. Есть куча дополнительных инструментов на любой вкус и цвет. Пожалуйста, покупайте, внедряйте
отсутствует детальный лог изменения конфигураций базы данных 1С. Т.е. в журнале регистраций нет возможности посмотреть, какие объекты конкретно были изменены, когда они были изменены, кем они были изменены. Убедиться, когда и что было изменено, практически невозможно.
Просто ерунда написана. Все эти возможности есть в истории хранилища.
Отсутствует механизм так называемого транспорта изменений для контроля за разработанными, протестированными и внесенными в рабочую базу данных изменениями. Если кто-то в своей работе сталкивался с SAP, то вы знаете, что там есть определенные структуры – есть транспорты, где можно всегда посмотреть, что, когда, куда, из какой среды было перенесено, и это легко проверить и увидеть.
Это можно контролировать метками и комментариями в хранилище.
Последний момент связан с этим же самым – механизм работы со средами разработки и тестирования. Да, вы можете создать отдельную базу данных для тестирования, отдельную для разработки, отдельную для промышленной эксплуатации. Но, к сожалению, прямой связки между базами, предназначенными для разработки и тестирования, все равно нет. Т.е. возможности напрямую убедиться, что все, что вы протестировали, вы перенесли в рабочую базу данных, все, что вы не протестировали, осталось в той базе данных – такой возможности нет. Это влечет за собой риск переноса в рабочую базу данных тех изменений, которые были изначально нежелательными либо просто непротестированными.
Хорошо, что вы предлагаете?
По Бизнес-Процессам забавно читать. Вы какую конфигурацию анализировали? Бухгалтерию 1.6 или 2.0?
