Функция изменения времени с учетом рабочих часов

5 50

Постановка задачи

Необходим типовой маршрут, да такой чтобы срок исполнения заданий был динамическим и предварительно уже рассчитанным в блоке сценария. Конкретнее: сотрудники технического отдела согласно внутренним стандартам находятся в жестких рамках решения поступившего вопроса так, например: не более 8 рабочих часов на анализ проблемы и информирование ответственного сотрудника, не более 16 рабочих часов на решение вопроса и так далее. Общее возможное затраченное время на решение не должно превышать более 48 рабочих часов (суммарное время на выполнение всей задачи).

Заметим, что если в свойствах типового маршрута устанавливать Относительный срок, допустим 4 часа, то отсчет данного времени начнется только после завершения работы с предыдущим заданием, а не от старта задачи. А в нашем случае необходимо будет из этих 4 часов вычесть время, затраченное на выполнение предыдущих заданий. (Здесь очень важна коллективная работа и ответственность каждого участника, ведь если один из сотрудников задержит выполнение своего задания к следующему исполнителю задание придет уже просроченным!)

Для вычисления данного вида срока была разработана функция «ChangeTime» изменение времени, подобная функции «ChangeDate».

Функция изменяет время (часы) от заданной даты и саму дату, если количество увеличенных  часов более 8 (напомню, подсчет осуществляется только в рабочих часах). Первоначально задается два параметра: Дата, требующая изменения и число часов, на которое требуется изменить время.

Далее в типовом маршруте первым блоком устанавливаем блок «сценарий» и прописываем вычисления на изменение даты и последовательно заносим полученные данные в параметры типового маршрута. И конечно не забываем указать параметры в свойствах блоков «Задание» в поле срок.

Пример:

//определим дату обращения клиента из справочника ТП 
 DateObr = СпрРекв(КодКомп;Код;"ДатаВремя";;;)
// изменить на 4 часа
 Four = ChangeTime (DateObr;4) 
 ТМУстановитьПараметрЗадачи("Four";Four)
// изменить на 8 часов
 Eight = ChangeTime (DateObr;8) 
  ТМУстановитьПараметрЗадачи("Eight";Eight)
// изменить на 16 часов
 Sixteen = ChangeTime (DateObr;16) 
  ТМУстановитьПараметрЗадачи("Sixteen";Sixteen)

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

Ниже предложен один из вариантов реализации функции для версии 4.5.1. и выше

ChangeTime.zip (2,03 Кб)

Денис Баранов

Есть еще недокументированный метод ServiceFactory.GetRelativeDate, который выдает дату-время, сдвинутую вперед на указанное число временных единиц с учетом календаря рабочего времени. Пример использования:

ВремяЧерез30Минут = ServiceFactory.GetRelativeDate(ServerDateTime(); 30 ; dotMinutes)

Алена Рунова

Спасибо за информацию, к сожалению не нашла описания в справке. Обязательно опробую данный метод!

Алена Рунова

Да, и вроде как данный метод не работает в разрезе рабочих дней, в отличие от функции.

 

Денис Баранов

Сегодня ServiceFactory.GetRelativeDate(ServerDateTime(); 3; dotDays) - показывает 15е число, т.е. выходные учитываются. Если отсчитывать в часах или в минутах, то учитываются рабочие часы. Проверял на DIRECTUM 4.6.1 (но и в других должно быть аналогично, этот метод не менялся уже очень давно). Правда, похоже, этот метод выдает все-таки не Дату-Время, а просто Дату... Т.е. "время через 1 рабочий час", к сожалению, им не получить. Так что функция нужна.

Дмитрий Тарасов

А какие еще есть недокументированные возможности DIRECTUM? А то тоже пришлось писать подобную функцию (правда для директум 4.4), а тут оказывается уже все готовое было :)

Рашит Сафиев

Да, лучше создать отдельную тему для этого, если их не мало...

А может в клиете есть еще и Easter Eggs ("пасхальные яйца")?:)

Дмитрий Тарасов

Давайте создадим, пусть директумовцы выкладывают, чтобы велосипед каждый раз не изобретать

Алена Рунова

 

Давайте создадим, пусть директумовцы выкладывают, чтобы велосипед каждый раз не изобретать

Поддерживаю!!

Михаил Извеков

>> Если отсчитывать в часах или в минутах, то учитываются рабочие часы.

И

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

Немного несоответствуют друг другу?

P.S. Метод возвращает именно Дату-Время.

Дамир Галимов

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

Возможно автор стал жертвой типичного недоразумения - если значение типа Дата-Время выводить на экран при помощи функции ShowMessage (она же Окно), то показывается только Дата. Поэтому даже если метод возвращает дату со временем (а это действительно так), то конструкция вида ShowMessage(ServiceFactory.GetRelativeDate(...)) покажет только дату.

Для корректного вывода на экран дат со временем используйте FormatDate...

Денис Баранов

Да, Дамир. Ты совершенно прав. Я слегка запутался из-за того, что ServerDateTime() в ShowMessage выводила дату со временем, а GetRelativeDate только дату. Сейчас посмотрел справку по ServerDateTime, оказывается там форматирование еще делается, поэтому и отображается.

Вывод - метод реабилитирован.

Дмитрий Тарасов

А метод ServiceFactory.GetRelativeDate(...) учитывает содержимое справочника "Календари рабочего времени" или учитывает только выходные?

Денис Баранов
А метод ServiceFactory.GetRelativeDate(...) учитывает содержимое справочника "Календари рабочего времени" или учитывает только выходные?

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

Дмитрий Тарасов

Круто! Выкидываю свою самописную функцию в утиль и беру на вооружение этот метод. Вот только бы описание к нему хоть какое-нибудь не помешало :(

Алена Рунова

Да работает в рамках календаря рабочего времени

Описание метода:

Получить дату, отстоящую от заданной, на заданное количество дней/часов/минут/секунд в соответствии с календарем рабочего времени.

Алена Рунова

GetRelativeDate – получить значение относительной даты

Синтаксис:

Function GetRelativeDate(

         StartDate: TDateTime;

         Number: Integer;

         NumberType: TDateOffsetType): TDateTime;

 

Входные параметры:

StartDate – дата, от которой рассчитывается относительная дата;

Number – величина смещения. Должна быть больше или равна 0;

NumberType – тип смещения.

Описание:

Получить дату, отстоящую от заданной, на заданное количество дней/часов/минут/секунд в соответствии с календарем рабочего времени.

Дмитрий Тарасов

Спасибо за информацию. Если не секрет, то откуда описание метода взяли?

Алена Рунова

isbobj.chm Справочная система по объектной модели.

Дмитрий Тарасов

Что-то никак не могу найти этот файл. Помню, что где-то натыкался на него, а где натыкался не помню :(

Скачал с сайта поддержки "IS Builder 7 7 Объектная модель DIRECTUM.chm", там нет описания данного метода. :(

Алена Рунова

Да, действительно этот файл - невидимка. Я его нашла в дистрибутиве Directum 4.3  ...\CLIENT\CommonAppData\NPO Computer\IS-Builder\7.5.1\Localization\en\isbobj.chm и больше этот файл нигде не встречался! Мне тоже очень хотелось бы получить полную версию объектной модели!

Денис Баранов

Ну, дело-то не в файле. Вовсе он не невидимка, это обычная справка по объектной модели. Входит в состав общей справки, вызывающейся по F1. У меня этот файл лежит тут: C:\Users\All Users\NPO Computer\IS-Builder\7.7.0\Localization\ru\ObjModel.chm (это путь для Win7, для остальных путь слегка другой, но тоже в All Users). Только вот описания этого метода там нет. Более того, если получить библиотеку типов sbrte в каком-нибудь просмотрщике этой самой библиотеки (например, в Object Browser VBA), то и там этот метод у IServiveFactory не обнаруживается. Не опубликован он в библиотеке. Но работает. Вот такой  секретный.

Алена Рунова

Согласна, но секретным метод стал, начиная с версии 4.3.1. правильно? а в версии 4.3. он был общедоступным . Почему же перестали публиковать данный метод?

Денис Баранов
Почему же перестали публиковать данный метод?

Это мне не известно.  Попробую выяснить. Может, Дамир что-нибудь скажет, раз он в курсе нашего обсуждения.

Михаил Извеков

Денис, файл isbobj.chm не может лежать по пути ...\ObjModel.chm

>> Более того, если получить библиотеку типов sbrte в каком-нибудь просмотрщике этой самой библиотеки (например, в Object Browser VBA), то и там этот метод у IServiveFactory не обнаруживается. Не опубликован он в библиотеке. Но работает. Вот такой  секретный.

Если взять не "какой-нибудь", а нормальный, то метод там будет (и будет помечен скрытым). Скрыли его для "облегчения" интерфейса IServiceFactory.

Денис Баранов
Денис, файл isbobj.chm не может лежать по пути ...\ObjModel.chm

Может, если его переименовали.

Скрыли его для "облегчения" интерфейса IServiceFactory.

Видимо, зря скрыли. Т.к. ничего взамен не дали... Я уже увидел, где его скрыли... в 7.5.0.

Алексей Язынин
Денис, файл isbobj.chm не может лежать по пути ...\ObjModel.chm Может, если его переименовали.

 

Именно поэтому служба поддержки постоянно просит указывать версию DIRECTUM в ваших обращениях. В данном случае дело в том, что файл действительно переименован в одной из версий системы. Указывая название файла имеет смысл конкретизировать для какой версии DIRECTUM вы это утверждаете.
Алена Рунова

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

Дамир Галимов
И все же почему перестали публиковать данный метод?

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

и много их таких...

Не мало. Но скрытых - абсолютное меньшинство :-)

Дмитрий Тарасов
Не мало. Но скрытых - абсолютное меньшинство

А как получить их список с описанием? :)

Дмитрий Тарасов

На мой запрос в службу поддержки они ответили:

"Метод GetRelativeDate объекта IServiceFactory не подлежит распространению, поэтому в документации он не описан.

Подобную информацию мы не предоставляем."

В принципе правильно ответили. Может тогда кто из разработчиков поделиться информацией по скрытым методам, а то вдруг там есть еще что-нибудь "вкусное"? :)

Михаил Извеков

Смотрите библиотеку типов в Sbrte.exe. Там всё есть

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

Андрей Подкин
А как получить их список с описанием?

Список - при помощи любого средства импорта COM Type Library, умеющего игнорировать флаг "Hidden". Например, Delphi.

Описание - только спрашивать у разработчиков.

Дмитрий Тарасов

Спасибо за информацию, но вот это:

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

сразу отпугнуло использовать скрытые методы :)

Может тогда где-нибудь на форуме обсудить какие методы стоит обратно открыть и чтобы их описание появилось в справочной системе? Мне вот, например, конкретно этот метод очень бы пригодился, но использовать теперь его рискованно :( Тем более выяснилось, что не только мне одному он нужен.

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

В книге Джоэля Спольски "Лучшие примеры разработки ПО" есть замечательное эссе Эрика Липперта "Сколько работников Microsoft нужно, чтобы сменить лампочку?"

Если найдете - не пожалейте времени, чтобы почитать.

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

Алена Рунова

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

Денис Баранов
Поэтому простым обсуждением в стиле "А давайте сделаем" действовать не получается.

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


Вот смотри, что написал Дамир:



если метод носит сугубо системное значение и/или не используется в стандартной прикладной разработке DIRECTUM и при этом загромождает объектную модель, то его скрывали. Основная цель - упростить объектную модель.

Где в этом методе "сугубо системное значение"? Вполне понятная прикладная задача - определить некий срок с учетом рабочего времени. Если те, кто согласовывал это изменение, не учли, что этот метод по смыслу не системный и потенциально может быть востребован, значит обсуждать такие вещи с конечным потребителем (в данном случае - прикладными разработчиками) все-таки нужно.


Дмитрий Тарасов

Присоединяюсь к мнению Дениса :)

Андрей Подкин
Т.е. ты против обсуждения?

Я против обсуждения ради обсуждения. Хотелось бы заранее увидеть свет в конце тоннеля его цель.

Где в этом методе "сугубо системное значение"?

Ну ведь очевидно же, что здесь просто ошиблись/перестарались.

Мы сейчас можем здесь обсуждать все, что угодно, но я не вижу, как и в какой конкретно версии что-то будет дорабатываться. Другое дело, если поставить глобально вопрос о доработках объектной модели, скажем, в концепцию DIRECTUM 4.8 - тогда можно будет к этому вопросу подойти системно и устранить множество подобных нелогичностей и непонятностей.

Дамир Галимов
Где в этом методе "сугубо системное значение"?

Денис, ты манипулируешь фактами, излагая их не полностью :-) Я писал: "...если метод носит сугубо системное значение и/или не используется в стандартной прикладной разработке DIRECTUM..."

Значит на тот момент метод не использовался. Если метод очень полезный, то всегда можно сделать прикладную функцию-обвертку, и уж она точно будет задокументирована. Хотя это уже будет выглядить еще более странно...

Денис Баранов
Ну ведь очевидно же, что здесь просто ошиблись/перестарались.

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

Я против обсуждения ради обсуждения. Хотелось бы заранее увидеть его цель.
Цель из предыдущего абзаца понятна? Люди хотят выяснить - чего еще от них полезного скрыли коварные разработчики. Увидят они, что больше там ничего нужного нет, и свет радости прольется на их души.
Мы сейчас можем здесь обсуждать все, что угодно, но я не вижу, как и в какой конкретно версии что-то будет дорабатываться.

По-моему, никто и не ждет, что тут будут озвучиваться какие-то обещания по изменениям платформы. Это неформальное общение, одна сплошная имха.

Другое дело, если поставить глобально вопрос о доработках объектной модели, скажем, в концепцию DIRECTUM 4.8 - тогда можно будет к этому вопросу подойти системно и устранить множество подобных нелогичностей и непонятностей.

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

Денис Баранов
Денис, ты манипулируешь фактами, излагая их не полностью

А как же иначе? Иначе будет скучно и пресно. У журналистов научился. Хотя, в данном случае, я не совсем с тобой согласен. Правильно я написал. Метод скрыли не потому, что он не использовался в стандартной версии, а потому, что решили, что он и не будет использоваться. Подумали что не нужен. До сих пор в стандартной версии DIRECTUM многое из открытой объектной модели не используется. Это же не стало причиной скрытия таких методов.

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

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

Вот именно для этих целей я и просил список скрытых методов :)

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

Тут я с Денисом полностью солидарен.

Андрей Подкин
Таких прецедентов, скорее всего, совсем немного.

А давай рассуждать на основе фактов (тем более, что их легко получить), а не предположений?

По-моему, никто и не ждет, что тут будут озвучиваться какие-то обещания по изменениям платформы.

Обещания здесь ни при чем. Я, как разработчик платформы, хотел бы понять для себя, когда я (чисто теоретически) мог бы заняться такими вещами. При текущем подходе мне этого не видно. Совсем.

Речь идет о напрасно скрытом методе, который ИМХО открыть не так уж дорого, как ты это пытаешься изобразить.

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

А как же твоя борьба с дублированием кода?

А это вообще какое отношение имеет к обсуждаемой проблеме?

Денис Баранов
А давай рассуждать на основе фактов (тем более, что их легко получить), а не предположений?

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

Таких прецедентов, скорее всего, совсем немного.

предположением споришь? Если нет, то зачем тогда нужны мне эти пресловутые факты? А если да, то тем более, разработчикам не лишне было бы узнать, какие из этих напрасно скрытых методов реализованы потом в прикладной разработке заново.

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

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

  1. метод уже используется в прикладной разработке (хоть и не в стандартной);
  2. метод востребован в новой разработке.

Итого, без внесения несовместимостей данный метод не убрать. И хорошей альтернативы ему сейчас нет.

А это вообще какое отношение имеет к обсуждаемой проблеме?

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

Андрей Подкин
разработчикам не лишне было бы узнать, какие из этих напрасно скрытых методов реализованы потом в прикладной разработке заново.

Денис, пока тут идет обсуждение, ты бы уже несколько раз успел запустить Delphi или Visual Studio и поискать слово Hidden.

Ты же любитель фактов, вот и посчитай

Опять попытка манипулировать. Конкретно про трудоемкость открытия метода начал рассуждать ты, так что с тебя и факты.

Пока я тоже вижу одни голословные утверждения.

Угу, вот только мои голословные утверждения опираются на мой ежедневный опыт работы. А твои на что?

Сделать прикладную функцию? Вот тебе и дублирование.

В каком месте? Это как раз типовой подход: сделать прикладную функцию и объявить, что с заврашнего дня разрешено использовать только ее. Для того, чтобы исключить потенциальные проблемы, функцию включить в стандартную разработку.

Денис Баранов
В каком месте? Это как раз типовой подход: сделать прикладную функцию и объявить, что с заврашнего дня разрешено использовать только ее. Для того, чтобы исключить потенциальные проблемы, функцию включить в стандартную разработку.

Т.е. сделать новую функцию проще, чем открыть существующий метод, и дублирования кода тут не будет? Функция-то что должна делать? Вызывать этот скрытый метод? Странновато выглядит. Или же ты предлагаешь на ISBL написать заново то, что уже написано в самом билдере?



Денис, пока тут идет обсуждение, ты бы уже несколько раз успел запустить Delphi или Visual Studio и поискать слово Hidden.

А лично меня этот вопрос и не интересует.



Угу, вот только мои голословные утверждения опираются на мой ежедневный опыт работы. А твои на что?

Мое предположение, на которое ты так ополчился звучало вот как:



Таких прецедентов, скорее всего, совсем немного.

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


Андрей Подкин
сделать новую функцию проще, чем открыть существующий метод

Значительно. Не надо:

  • выпускать билд IS-Builder;
  • синхронизировать разработку в N веток системы контроля версий (все поддерживаемые для текущей версии системы + разрабатываемая);
  • обновлять официальную документацию и выпускать ее билды в CHM и PDF;
  • и прочая и прочая.

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

дублирования кода тут не будет?

Где именно?

Вызывать этот скрытый метод? Странновато выглядит.

Почему?

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

Нет, не так. И не ополчился.

Денис Баранов
Почему?

Вот поэтому:

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

 

Значительно. Не надо:
Это все понятно... Но ты описываешь процесс выпуска версии, который произойдет в любом случае, независимо от наличия/отсутствия изменеий по данному методу. Ты всерьез считаешь, что мы тут обсуждаем выпуск обновления DIRECTUM ради убирания флага Hidden с одного метода?
Единственный аргумент из приведенных, который можно тут рассматривать - это синхронизация разработки в системе контроля версий. Да и то в данном случае достаточно только в текущем разрабатываемом билде этот метод восстановить, без синхронизации в старые. Даже документация на метод и то уже существует - бери и включай в сборку очередной версии.
Где именно?

В билдере в любом случае будет метод или функция получения относительного срока, т.к. это необходимо службе workflow. Мы либо дублируем эту функцию на уровне прикладной разработки (переписываем на ISBL, что неправильно т.к. это дублирование), либо используем билдеровский метод (что тоже неправильно, ибо он вроде как скрыт и без поддержки).

Нет, не так

См. коммент: Андрей Подкин, 11 марта 2010, 15:03

Видимо, в данном случае возникло недопонимание.

Алена Рунова

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

Андрей Подкин
Вот поэтому:

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

Ты всерьез считаешь, что мы тут обсуждаем выпуск обновления DIRECTUM ради убирания флага Hidden с одного метода?

Конечно. Например, без нового билда у тебя физически не появится нового метода в документации. Ибо такова технология и инструменты автоматизации. А без документации и смысла открывать нет.

Да и то в данном случае достаточно только в текущем разрабатываемом билде этот метод восстановить, без синхронизации в старые.

Так в разрабатываемом или в текущем? Если в текущем, то в каком из? Хорошая система контроля версий + разделение разработки и поддержки здОрово првоцируют на множественные бранчи, знаешь ли

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

См. выше. Если мы выкинем этот метод, то расскажем, на что его заменить.

Авторизуйтесь, чтобы написать комментарий