mentos
Егор Ермаков

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

(16) YOr!k, я за кроссплатформенность. и то что "unpack" этому мешает - меня оооочень огорчает. чувство прекрасного сильно страдает и заливается горючими слезами. но раз и так все плохо - это не повод делать ещё хуже и использовать мерзкие com-объекты.

(12) YOr!k, com-объекты зло!! нужно забыть про них!

(8)

Цитата
1) Да, согласен

тогда уж и заполнение всех остальных реквизитов сделать автоматическим, в случае совпадения имени параметры и имени реквизита. может не сразу, а по кнопке.

1) имеет смысл при связи со строкой ТЧ автоматически заполнять параметры совпадающие по именем с реквизитами ТЧ
2) нельзя сразу во внешние обработки сохранять, не выгружая в файл?
3) неплохо бы вопросы пользователю научиться задавать, чтобы он какие-то параметры перед печатью мог ввести
4) с областями не очень понятно где какая.. т.к. они в макете не отображаются никак
а так прикольно. покажу отделу сопровождения, может им интересно будет

Цитата
Пользователей хранилища мы называем по имени базы на 1с сервере.

вот за это спасибо :) простейшая вещь, но в голову никогда не приходила

"Но все равно ведь 1С в режиме предприятия будет запущенно. " - да, но один запущенный тонкий клиент не мешает. По-крайней мере мне.

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

Но бывают задачи и не выставленные в мантис: всякие внепроектные, совещания, обучение, обеды, перекуры и т.д.

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

Redmine, JIRA, Mantis - это замечательно!
Но эта система позволяет существенно ускорить и упростить учет затрат рабочего времени на задачи. Особенно если использовать ее в связке с вышеперечисленными системами (пока поддерживается только Mantis). Благодаря ей мы ведем учет с точностью до минуты (количество "переключений" задач для одного разработчика в авральные дни может доходить до 20ти и более), при этом на сам учет мы время практически не тратим. Система сама грузит задачи из Mantis, мы только указываем при переключении на следующую задачу, что делаем теперь ее (Элегантным движением мыши перетаскиваем задачу из списка задач к выполнению в табличку-табель текущего дня). А если учесть как легко там обновляются плановые трудозатраты, то руководитель всегда имеет плановую дату завершения задачи (она рассчитывается сама исходя из плановых трудозатрат, текущих фактических и номеру задачи по списку).
В общем мы в команде экономим кучу времени используя ее, а так же знаем с точностью до минуты сколько затратили на ту или иную задачу или на проект в целом.

и ещё здесь нашли решение http://www.forum.mista.ru/topic.php?id=630618

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