Поделюсь мыслью

[Yoil]

В Инкадее и в Брайт-авто используется следующая штука:
при логине в Нав, в первом кодъюните в таблицу User Session прописываются склад по умолчанию, (для юзера типа кладовщика, например, которого вообще не волнуют никакие склады, кроме того, где он работает), туда же запоминается логин юзера (чтобы потом прописываться в поле USer ID заказа продажи, например, который создает юзер) и т.п.


UserSession.RESET;
UserSession.INIT;
UserSession."Session ID" := Session."Connection ID";
IF NOT UserSession.GET(Session."Connection ID") THEN
UserSession.INSERT(TRUE);
UserSession."User ID" := User_ID;
UserSession."Location Code" := Locations.Code;

И прочая чепуха


Не знаю, каким хреном, но я такой не один (в смысле есть еще жертвы Инкадеи и Брайт-консалта, у которых данная проблема есть)
В момент создания документа (перемещение, заказ продажи, акт списания-оприходования) в этой самой таблице User Session в поле "Location Code" у рядового юзера вместо его правильно склада 'Правильный склад' оказывается значение 'совсем другой склада'
А дальше юзер смело учитывает документ и потом негодует, какого хрена движение получилось не со склада 'Правильный склад', а с какого-то совершенного непонятного для юзера 'совсем другой склад' (юзеру абсолютно не нужно знать, что есть в заказе продажи закладка "Поставка", на которой видно склад, с которого пойдет продажа, его волнуют совсем другие вещи, он кладовщик, например). Ну, или, бухгалтерия негодует. Или еще кто-нибудь, кого это касается.

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

Я, в целом, очень ленив и предпочитаю смотреть котиков в интернетах, чем разбираться с какой-то неведомой непонятной хренью, которую и написал не я, и как она устроена, я не угу, и почему она глючит, хрен ее знает.
Поэтому проблему я решил примерно за 10 минут и забыл про нее.
Объявил в пользовательском диапазоне кодъюнит со свойством SingleInstance = Yes
Объявил в нем две функции - SetParams и GetParams, через которые пишутся и читаются необходимые параметры типа кода склада по умолчанию.
Изменил функцию GetLocation в таблице User Session, чтоб отдавала данные из моего кодъюнита, а не из этой самой неведомой таблицы
Ну и в 1-м кодъюните переписал вместо вставки

UserSession."Location Code" := Locations.Code;
UserSession.INSERT;

передачу кода склада в мой синглинстанс-кодъюнит
Т.е. что-то типа
Вместо UserSession."Location Code" := Locations.Code пишу
MybeautifulCodeunit.SetDefaultUserLocationCode('нужный код склада');

На всякий случай на первое время дописал еще ведение логов обращения к этому самому коду склада, что выдает мой вариант с синглинстансом, а что отдает User Session
Через два дня стало очевидно, что вариант с синглинстансом отрабатывает на 100% корректно.

А вот что там поломалось в этой гребанной User Session, я так и не знаю, котики прикольней.


Вот такая занимательная история произошла со мной пару лет назад.

[alexb_imported]

Цитата:

Сообщение от Дуд

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

Позволю вставить мои 5 копеек в дискуссию:
меня, напротив, часто интересует:
1) смысл кода;
2) если код не работает -> почему не работает.
На поверхностный взгляд и согласно комментарию Дуд'a смысл приведённого Инкадеи / в Брайт-авто кода в том, чтобы привязать к юзеру определённый склад чтобы передать оный склад в функции учёта и т.д. Чем программисту Инкадеи / Брайт-авто не понравилась стандартная таблица 7301 "Warehouse Employee" в которой именно и можно поставить юзеру галочку в складе по умолчанию и потом брать склад из этой таблицы в ЛЮБОМ месте программы? Или например, если не нравится таблица 7301 "Warehouse Employee", то почему бы не завести в таблице 91 "User Setup" новое поле "Default Location Code" и использовать его? И тогда не нужны были бы эти пляски с бубном с никому непонятной таблицей "User Session" (которая то заполняется то нет, то с правильным складом то с неправильным) На мой взгляд это типичное паралельное программирование, когда паралельно к существуемому НАВ стандартному функционалу придумывается новый костыль чтобы достичь того же самого, что повышает риск возникновения ошибок. И потом отвечай в суппорте на вопросы типа: "У юзера ХХХ стоит в таблице "Warehouse Employee" галочка "Default" для склада "BLUE". Почему в заказе продажи стоит "RED"?" Начинаете копаться и находите, что согласно супер-фьюче от инкадеа "RED" приходит из непонятной таблицы UserSession. Потом приходит следующий вопрос: "а почему тогда иногда то "RED" то "ORANGE"?" Начинаете опять копаться и находите, что супер-фьюча работает иногда правильно а иногда нет, то "Connection ID" не тот (-> см. jopagames3), то ещё почему-то. Вместо того чтобы исправить первый костыль и устранить первопричиину от инкадеа (а было бы ещё лучше вернуться к СТАНДАРТ'у посмотрев где везде в программе используется UserSession."Location Code" и заменив его на "Warehouse Employee"."Location Code" либо на поле из "User Setup"), программируется новый костыль с SingleInstance-Codeunit, который опять же чреват ошибками, т.к. свойство SingleInstance довольно деликатное дело.

Цитата:

Сообщение от Дуд

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

Тоже загадка типа "почему делать всё просто когда можно через ж...!". Т.е. сначале берём из системной функции "USERID()" ID юзера, пишем оный в таблицу UserSession и потом оттуда (если нам повезло и запись в UserSession создалась!) пишем этот UserID в заказ продажи? А ведь можно тупо в OnInsert()-триггере заказa продажи присвоить полю UserID в заказе продажи сразу напрямую из системной функции "USERID()".

[artkashin]

Цитата:

Сообщение от jopagames3

Цитата:

Сообщение от Дуд

UserSession.RESET;
UserSession.INIT;
UserSession."Session ID" := Session."Connection ID";
IF NOT UserSession.GET(Session."Connection ID") THEN
UserSession.INSERT(TRUE);
UserSession."User ID" := User_ID;
UserSession."Location Code" := Locations.Code;

А если без стеба и по делу, то так делать вааще нельзя.

Поскольку первичный ключ таблицы - Connection ID, который назначает сессии непосредственно скуль.

Т.е. он при обрыве связи, или когда юзера вышибают с терминального сервера может запросто присвоить такой же Connection ID другому, следующему подключившемуся к SQL пользователю (с другим userid в Навике)

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

Но раз исправил, так исправил. Главное - работает! :-)

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

[Yoil]

Цитата:

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

Сережа, я выгнал ровно одного бесполезного программиста, тебя.
Остальных двоих сократили, я был решительно против, но не помогло.

[Yoil]

AlexB, смысл не совсем в том
У юзера может быть доступ, например, к двум складам, ORANGE и RED.
В таком случае при логине в систему после выбора фирмы он также выбирает из открывшегося списка склад, который у него будет по умолчанию прописываться во вновь открытые документы - ORANGE или RED.
Типа сегодня он работает на складе RED - выбирает при логине его.
Завтра на ORANGE - выбирает ORANGE.

[alexb_imported]

Цитата:

Сообщение от Дуд

AlexB, смысл не совсем в том
У юзера может быть доступ, например, к двум складам, ORANGE и RED.
В таком случае при логине в систему после выбора фирмы он также выбирает из открывшегося списка склад, который у него будет по умолчанию прописываться во вновь открытые документы - ORANGE или RED.
Типа сегодня он работает на складе RED - выбирает при логине его.
Завтра на ORANGE - выбирает ORANGE.

Если юзер выбирает при каждом логине склад - хорошо. Я ведь критикую то как это было спрограммировано и в этом смысле солидарен с jopagames3 и с Kashin. Вот мой (навскидку) вариант: юзер выбирает при каждом логине какой-то склад, берём этот склад, пишем в СТАНДАРТНУЮ таблицу "User Setup" в новое поле "Default Location Code" и пользуем склад из этого поля в закзах продажи итд итп. Если юзер вылетел из NAV'a и сессия зависла - ну и чёрт с ней, нам нужен склад а не ConnectionID или что другое, при следующем логине юзер опять выбирает опять требуемый склад, который опять же пишется в "User Setup" и опять же используется в требуемых процессах. И этот вариант по моему мнению наименее критичен в плане того, что в заказе продажи каким-то макаром всё-таки нет да и пропишется неправильный склад, т.е. менее критичен Inkadea-варианта с UserSession и Вашего варианта с SingleInstance-Coduenit.

[rmv]

Цитата:

Сообщение от Дуд

AlexB, смысл не совсем в том
У юзера может быть доступ, например, к двум складам, ORANGE и RED.
В таком случае при логине в систему после выбора фирмы он также выбирает из открывшегося списка склад, который у него будет по умолчанию прописываться во вновь открытые документы - ORANGE или RED.
Типа сегодня он работает на складе RED - выбирает при логине его.
Завтра на ORANGE - выбирает ORANGE.

Тем не менее решение с сессиями имеет смысл только в том случае, если в одном экземпляре Нава юзер выбрал ORANGE, а в другом RED, противном случае ничего не мешает дать косвенные права и заполнить дефолтовую галку в том же Warehouse Employee.
Могу предположить что ноги такого решения растут от того, что определенной группе сотрудников (кладовщики на разных складах к примеру) назначается один логин на вход в Нав.

[alexb_imported]

Цитата:

Сообщение от rmv

Тем не менее решение с сессиями имеет смысл только в том случае, если в одном экземпляре Нава юзер выбрал ORANGE, а в другом RED...

Разумеется, если юзер работает в НАВ одновременно в нескольких НАВ сессиях с разными складами, тогда имеет смысл смотреть в таблицу Session. И если здесь возникают проблемы, то надо постараться проблемы решить. Например проверить, фильтруется ли в коде таблица Session по полю "My Session"? Что стоит в поле "Idle Time"? Наконец использовать ту или иную НАВ тулзу / прогу по чистке зависших сессий, короче ремонтировать данный костыль а не программировать новый.

[Yoil]

Цитата:

короче ремонтировать данный костыль а не программировать новый

почему?
учитывая, что по результату работы логов новый костыль отдавал на 100% корректные данные?
зачем мучить старый костыль, развейте мысль

[alexb_imported]

Цитата:

Сообщение от Дуд

зачем мучить старый костыль, развейте мысль

Ну хотя бы вот по каким причинам:
насколько я понимаю кусок периодически нерабoтающего кода ("старый костыль") - не Ваш customizing а родом из какого-то AddOn'a третьей конторы (инкадеа или что другое). Допустим у клиента опять возникла проблема со складом, он обращается в суппорт, в суппорте смотрят: ага, затронут процесс привязки user&location который является частью AddOn'a от инкадеа и отсылают в суппорт этой конторы (инкадеа). Программист из инкадеа начинает анализировать и натыкается на то место, где инкадеевский код закомментен Вами и земенен Вашим кодом ==> программист из инкадеа умывает руки, дескать, мы здесь не причём и суппорт-вопрос возвращается в Вашу контору. Или другой случай: инкадеа выпустила обнобление по своему АddOn'у, в котором теперь, например, костыль исправлен, или костыль расширен на доп. функционал -> что, будете, дублировать доп. функционал в Вашу SingleInstance-CU? A если это обновление клиенту заливаете не Вы а другой программист (Вы в отпуске и Вас временно замещает например какой-нибудь Сергей /> , который ваш костыль не знает / не понял его смысл), и залил (используя TextMerge) это обновление клиенту так, что ни инкадеа-вариант ни Ваш вариант вообще перестали работать? Согласен, когда аврал, можно на скорую руку что-то сварганить чтобы проблему клиента решить. Но после аврала надо послать запрос в инкадеа с описанием проблемы, чтобы в долгосрочном плане первоначальная проблема ("старый костыль") была решена и инкадеевский код заработал на 100%. Всё это, само собой, моё личное мнение (тема же называется "поделюсь мыслью"), а так же генеральная линия в моей конторе. Иначе эдак можно при любой ошибке в CU 80 не мучиться поиском причины а сразу закомментить проблемный код стандарта и делать ответвление из CU 80 в MybeautifulCodeunit и на супорт-запросы в MS просто забить.

[Yoil]

Мда, при таких условиях - на 100% с вами согласен.
Просто к тому моменту все осуществлялось своими силами.