Как блокировать одновременный доступ к Заказу?

[блондинка]

Товарищи по Axapta, подскажите, пожалуйста, никто не сталкивался с такой задачей:

Необходимо не допускать одновременной работы 2х и более пользователей в одной шапке(строках) Заказа/Закупки.
Работаем на 2х звенке, Axapta 3.0.

Цитата:

Сообщение от блондинка

Товарищи по Axapta, подскажите, пожалуйста, никто не сталкивался с такой задачей:

Необходимо не допускать одновременной работы 2х и более пользователей в одной шапке(строках) Заказа/Закупки.
Работаем на 2х звенке, Axapta 3.0.

Глупый наверное вопрос, но зачем?

[glibs]

lagr221374, на ник посмотрите.

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

Первого нет, а второе можно почерпнуть в журналах ГК и складских журналах.

Цитата:

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

lagr221374, на ник посмотрите.

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

Первого нет, а второе можно почерпнуть в журналах ГК и складских журналах.

Ну почему нет первого? Можно создать одного user-а и только ему дать права для работы с заказами. Все остальные в сад...
Другой вопрос что для работы это не удобно...но такова жизнь

[mazzy]

Цитата:

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

Можно создать одного user-а и только ему дать права для работы с заказами.

Радикально.
Вообще говоря, лучше настроить RLS на поле Ответственный продавец.
При создании это поле заполнять в обязательном порядке.

[блондинка]

Большое спасибо за активное участие!

Жизненная ситуация такая:

Выделить отдельного "ответственного" за Заказ административно невозможно, да и не требуется. Желание только не мешать друг другу одновременной работой.

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

Цитата:

Сообщение от блондинка

Большое спасибо за активное участие!

Жизненная ситуация такая:

Выделить отдельного "ответственного" за Заказ административно невозможно, да и не требуется. Желание только не мешать друг другу одновременной работой.

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

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

[Lokis]

Можно попробовать реализовать с.о.
1. Создаете табличку (salesTableLock), в которой поля: SalesId, UnitId (1, 2:Заказы\Закупки), createdBy, createdDate, createdTime
2. На примере Заказов: Перегружаете в форме salesTable метод active, в котором:
2.1 Делаете проверку на наличие в SalesTableLock записи с salesId == SalesId из текущего курсора, и, если находите, то на форме д.б. метод editsales (я в 2.5 работаю). Вызываете его с параметром false. Посмотрите методы datasource формы AlowEdit, AllowCreate, AllowDelete... Можете выдавать сообщение пользователю.
2.2 Удаляете все записи из табличке salesTableLock, у которых createdBy == curUserId() и, сот-но, модуль == 1:заказы
2.2 Вставляете запись в salesTableLock, salesId из текущего курсора, UnitId = 1

Это навскидку, изврат конечно. Наверняка есть подводные камни. Например пользователь может перезагрузить комп, и тогда запись зависнет в таблице. Тогда нужно определять пакет, который будет чистить "подвисшие" записи, а идентифицировать их, ну, скажем по времени захвата. Сколько времени Заказ может быть захвачен? Решать вам.
Да, и лочить запись нужно так же в момент создания.
3. В форме SalesCreateOrder в конце метода initvalue. В противном случае, пока пользователь создает новую запись, другой вошедший в форму "Заказы" может ее заблокировать.

[glibs]

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

Это теоретически. Реально я бы ничего из вышеперечисленного делать не рекомендовал (слишком много кодирования из-за ерунды какой-то).

[ziva]

Цитата:

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

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

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

блондинка,
Журналы то это одно - там отдельная форма строк, открытие которой можно заблокировать. А вот форма заказов совсем другая. Представьте себе что имеем 10 заказов. Один пользователь на 1м. Второй на 10м. И начинают они "бежать" (с помощью стрелочек на клавиатуре) по гриду - первый - вниз, второй - вверх.
Что происходит в районе примерно 5го по счету заказа если они одновременно на нем "остановились"?
Вы вообще думали о той бизнес-логике которая должна при этом отрабатывать? Для каждого пользователя:
1. Перечитать запись из БД.
2. Проверить флаг
а. Блокирован - блокируем заказ от изменения текущим пользователем (строки + все кнопки)
б. Не блокирован - обновляем в транзакции флаг в заказе. Перечитываем запись в датасорс. Можем осуществлять работу с заказом.
3. Ушли с этого заказа - обновить запись в БД., разбликировать строки и кнопки ... и далее на п.1
Короче, бред....

А кроме обычной формы заказов есть форма "Строки открытых заказов" (или как она там называется... Аксапты под рукой нет). Там такую же хрень реализовывать?