Как разорвать все связи объекта в действии Party

[Александр]

gali ты не одна - я сам рисовал настройку под 1280х1024 т.е. под 17'' так мало того что у некоторых до сих пор стоят 15'' так кое кто еще и текст ставит не стандартный а укрупненный (все съезжает туда суда)- когда я вижу что отрисовывается на клиентских местах я прихожу в тихий ужас - но лоция то никак не соберется сделать нормальное масштабирование с привязкой к текущим настройкам
так что пытался рисовать ориентируясь на 1024х768 с учетом укрупненного шрифта потом правил это на 1280х1024 с нормальным шрифтом - потом по кругу и по кругу, а потом плюнул на все на это - и сказал - работайте ребята на 17 дюймах и купите очки если плохо видно -шутка конечно но печальная...

Правда сейчас переходим на широкоформатные 19'' вот здесь уже с какими нибудь навороченными темами от Висты Лоция блистает во всей красе, но 15'' пока держат - вобшем - кошмар

[Disillusioned]

Неоднозначность поведения пользователя может быть исключена только после отказа от использования неоднозначного функционала. В случае повторной регистрации документа заведи кнопку "Удалить ошибочно зарегистрированный документ", если документ аннулируется пусть будет кнопка "Аннулировать документ".

P.S. Лично мне не очень понятен смысл удаления объектов из БД, т.к. данный процесс разрушает данные истории проекта (история проекта есть величайшее благо и панацея от пользовательской безответственности). Ведь можно эти объекты/атрибуты изменить так, что они никому не будут мешать?!

[gali]

мудрые слова!
но вот какая штука. Сделав несколько форм под конкретные задачи, ужаснулась разведенным зоопарком. Если добавить многообразие действий, опять же под конкретную задачу, картина вырисовывается жуткая. Поэтому появилось желание унифицировать визуальные приемы и действия свести к миниму. В регламентированных задачах проще: можно водить строго в рамках. В случае с удалением запускать (родилось в обсуждении) универсальное действие, но с параметром, что требуется сделать в этом конкретном случае.

P.S. Лично мне не очень понятен смысл удаления объектов из БД, т.к.

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

[Disillusioned]

Определение элементарных действий и взаимодействий осуществляемых пользователями - это один из первых этапов разработки и если нужно иметь 20 кнопок пусть будет 20 (хотя конечно количество элементарных действий не обязано быть равно количеству кнопок). Можно каждый чих программировать, а можно укрупнять и минимизировать функционал. Важно одно, пользователь не должен много задумываться, не должен иметь большого выбора, он ему и не нужен, никому не хочется тратить время на сомнения по поводу "правильного" использовании Лоции, когда этих сомнений полно и по основному роду деятельности.

Насчет удаления: если предположить что только автор(создатель) объекта может осуществить его удаление из БД (помещение в корзину) и при этом он 100% владеет данными о необходимости(полезности) удаляемого объекта другим пользователям, тогда удаление из БД, на мой взгляд, допустимо. Но какой в нем практический смысл? "Ошибочных" объектов не так уж и много (единицы % от общего числа) и на размер БД они принциально не влияют. Чтобы они особо не мешались при поиске, можно соответствующим образом изменить(испортить) им описание и атрибуты (атрибуты можно и вовсе удалить, для того история изменений есть). И при этом можно быть уверенным, что НИКАКАЯ информация, введенная пользователем, не будет утрачена (быть может ее не всегда будет просто найти, но она в БД будет!).

Благодаря истории изменений вполне можно реализовать функционал, "откатывающий" состояние проекта на определенное временное состояние (не касается документов). Если взять за правило удаление объектов из БД, об этом не стоит и мечтать.

P/S/ Если честно, раньше тоже, с удовольствием "чистил" базу, сейчас считаю, что это концептуально противоречит архитектуре Лоции (о чем косвенно свидетельствует "строгость" предупреждения при удалении объектов из БД)

[gali]

Disillusioned, правильные замечательные мысли. Только я склоняюсь к минимизации всяческих объектов. И форм с повторяющимся дизайном в том числе. И для пользователя лучше, когда в любом месте картинка с корзиной сопровождается одинаковым текстом и ожидаемым результатом.
А вот про удаления объектов не могу согласиться полностью (возможно, из-за недостаточного опыта работы с лоцией, но тем не менее). Если говорить о документах, например, служебных записках, заказах и пр., имеет смысл хранить. Но не зря существуют сроки хранения для бумажных документов. Какой смысл хранить то, что никому не надо или то, что достать/найти сложно?
Если пользователю дать свободу действий, он такого натолкает в свои папки! Хорошая иллюстрация тому пухнущий пользовательский каталог, который периодически режут наши сисадмины.

[Александр]

дайте вставить 3 рубля - мы тоже удаляем объекты Но это все последствия повального импорта - и то что юзеры ввели повторно не озадачившись поиском т.е. действительно мизер от общего количества.

А так по большому счету у нас вообще нет объектов на удаление - они както сами проходят вне базы

[Disillusioned]

Ну естественно, универсальных подходов не бывает, просто для меня "чем проще правило, тем проще ему следовать", т.е. не удалять объектов из БД, значит не удалять никаких.

Что касается удаления по истечению срока хранения, это дело нужное (особенно, если БД распухла). Но, по моему, это не то удаление, которое обсуждается в данной теме (удаление по решению пользователя). Это строгий регламент, прописанный документально (объекты отбираются по формальным признакам). к тому же, как правило, перед такими удалениями (производимыми обычно ежегодно), делают резервную копию данных и хранят ее долго-долго....и никакие данные, никогда не будут утеряны, и всех ждет вечная молодость!
К слову сказать, за те годы, что я с Лоцией работаю, нужды в удалении по сроку давности ни разу не возникло (если честно пока и не предвидится)

Повальный импорт тоже другое дело - удаляем то чего и быть то не должно...

[gali]

просто невозможно возражать правильным мыслям!
Но хочется быть услышанным (услышанной).
Disillusioned, смотри, такая ситуация.
Мы делаем первые шаги по внедрению электронного документооборота. Реально все это только слова. Потому как то, как это происходит далеко от формулировки. То, что мы пытаемся делать никому не нужно. У нас крутится полторы задачи и те со скрипом. Не хочет народ работать. Проще сходить ногами, чем нажимать на кнопки. Но вслух об этом говорят мне, а у руководства доводы другие: не удобно. Ради этих 1.5 задач надо запускать лоцию, которая все время вылезает, когда работаешь с офисными приложениями.
Поэтому возникла мысль дать пользователям инструмент самим порождать и служебные, и заявки, и отчеты, и др. до тех пор, пока мы доберемся до реализации этих процессов в соответствии с процедурами качества.


Александр, и тебе спасибо

[Disillusioned]

gali, твоя ситуация мне знакома до боли, но она носит чисто организационный характер, т.к. внедрение систем, подобных Лоции, требует воли руководства и желание простого пользователя работать в ней, хоть и очень полезно для внедренца, т.к. бережет нам нервы, но в корпоративном масштабе мало что решает (ИМХО). Ведь их же пользователей много, бывает что сотни, и у всех вкусы разные, и если верить теории вероятности, то некоторые из них вполне могут оказаться маньяками и извращенцами (чтобы не любить Лоцию, вовсе не обязательно быть извращенцем, достаточно просто иметь плохое зрение) . А чтобы был электронный документооборот, нужно чтобы КАЖДЫЙ работал в соответсвии с регламентом.
В свое время неоднократно пытались запустить электронный документооборот, но пока не появился человек, который пробил, чтобы обязанность исполнять руководство пользователя внесли в должностные инструкции, так все и шло через пень колода. А теперь, пожалуйста, даже согласование в электронном виде, на бумаге только утверждающий расписывается и по большому счету все довольны.

Что касается неудобства работы, то работать в принципе неудобно, дома то оно куда приятнее (т.е. для руководителя это сомнительный довод).

А вот ODMA точно лучше отключить, люди тебе спасибо скажут.

P.S. Это я к тому, что не стоит переживать из-за того, что мы не в состоянии изменить.

[gali]

требует воли руководства

известные вещи! еще в школе проходили.
А что делать, если этого самого необходимого нет? Спросишь, с чего вдруг решили внедрять? Надо соответствовать времени. Заказчики нынче грамотные, прежде чем, спрашивают: а это у вас есть? а то?

А чтобы был электронный документооборот, нужно чтобы КАЖДЫЙ работал в соответсвии с регламентом.

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

Что касается неудобства работы, то работать в принципе неудобно, дома то оно куда приятнее

вредная посылка, по себе сужу

[Disillusioned]

"Соответствовать времени" так себе аргумент, конечно, но надо понимать, что твои оппоненты, скорее всего, умные люди и прекрасно понимают, что ты внедряешь инструмент, который их же и будет контролировать. Поскольку никто не хочет ограничений в собственной свободе, имеем, что называется, результат. И это при том, что как раз электронный документооборот (не технический) и в разработке и в обучении пользователей относительно легок и эффект от него очень даже заметен массам (по сравнению с PDM).
Но собственно, мои умозаключения тебе жизнь совершенно не облегчат, просто поверь, что насчет неудобства, брехня все это (из собственного опыта: пользователи и их руководство с год жаловались что мол не удобно им работать, переработали мы интерфейс, старались как только могли, да и вышло неплохо, но подижь ты, больше года никто новую разработку не использует, работают по старому и по-прежнему жалуются). ПОЛИТИКА

P.S. Друг на друга они жалуются точно также.

[gali]

Далековато мы ушли от задекларированной темы.
А чтобы действительно жизнь мне облегчить , лучше подскажите, как с атрибутивной формы передать в действие, запускаемое кнопкой, информацию (код связи, или ид объекта, или еще что-то) о родителе текущего проекта (дерева).
Т.е. есть объект ВАСЯ. Он входит в проекты СОТРУДНИКИ и ГИПы. Находясь в дереве ГИПы, жмем кнопку. Хочу однозначно получить родителя ВАСИ из дерева ГИПы.
Можно? Как?

[Disillusioned]

Кроме как f_ExecSQLSelect_3, ничего в голову не приходит. Только Keep не забыть задать несколько секунд.

[gali]

Не поняла совета. Навеное, мысль работает не в ту сторону Или не освоила всех прелестей новой функции.
Давай по порядку.
Открыто окно с деревом ГИПы. Встаем на объекте ВАСЯ. Жмем кнопку, запускается действие, в котором должно быть однозначно установлено: Объект ВАСЯ, родитель ГИПы, код связи такой-то.
С ВАСЕЙ ясно, это текущий объект. Как я должна написать запрос, чтобы среди всех родителей ВАСИ достать только ГИПы?

Я в действии настроила переменную типа объект, указала поиск по связи с текущим объектом - выдает всех родителей.
Код текущей связи не определен.
Тупик

[Александр]

а keep то зачем??? ведь запрос одноразовый судя по всему