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

[Beast-L]

Цитата:

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

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

Перечитайте совет еще раз.

Думать это хорошо. Только вы попробуйте объяснить это тем пользователям которые этого делать не хотят. Если бы они думали то мне бы не нужно было такую задачу выполнять.

[Beast-L]

Цитата:

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

В одном месте вы говорите, что нельзя менять через Сервис\Системная дата. Без оговорок.

Имелось ввиду в той компании в которой нужно запретить пользователю смену даты.

Цитата:

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

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

Ну правильно в одной нужно запретить в другой разрешить.

Цитата:

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

В третьем, что сменив дату в третьей компании... нельзя МЕНЯТЬ в четвертой.

Извеняюсь может чего-то не так говорю но ниокаких третих и четвёртых я не говорил.


Давайте попытаюсь сказать иначе:

1) Нужно запретить в зависимости от компании смену системной даты пользователем вручную через сервис - системная дата или через двойной щелчёк по дате в статусе окна Axapta (запрещать смену даты в коде стандартных и других модулей не нужно).

2) Сбрасывать системную дату по серверу при переходе из компании в которой разрешено менять системную дату в компанию в которой запрещено менять системную дату.

Кроме того вариант с закрытием периода не подходит по двум причинам:
1) Дописаный функционал не имеет контроля этих периодов
2) Запрет изменения системной даты нужен в пределах дня, тоесть в случае использования закрытия периодов нужно будет закрывать каждый день период длительностью в один день. Кроме того некоторые умельцы умудряются вносить данные наперёд.

[petr]

А нельзя на validateWrite определенных таблиц повесить проверку на дату и если дата введенная пользователем отличатеся от today() то просто выдавать ошибку и активировать эту проверку только для определенных компаний.

[Beast-L]

Цитата:

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

А нельзя на validateWrite определенных таблиц повесить проверку на дату и если дата введенная пользователем отличатеся от today() то просто выдавать ошибку и активировать эту проверку только для определенных компаний.

Теоретически можно но это займёт очень много времени и ещё больше на вылавливание глюков после этого.

[glibs]

Цитата:

Сообщение от Beast-L

...
2) Сбрасывать системную дату по серверу при переходе из компании в которой разрешено менять системную дату в компанию в которой запрещено менять системную дату.
...

Это уже похоже на логичную постановку задачи.

Можно запрограммировать в форме выбора компании.

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

[Beast-L]

Ну хорошо давайте предположим что нет никакого доработаного функционала. Как в этом случае решить такую задачу?

[glibs]

petr вам уже написал. Только today() должно вызываться на АОСе.

[Beast-L]

Ещё какие нибудь варианты есть?

[Владимир Максимов]

Цитата:

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

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

Цитата:

Сообщение от Beast-L

Всё дело в трудозатратах. А вообще если заплатят - напишем.

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

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

Вот и оцените, какие трудозатраты будут выше: допиливание ранее сделанного функционала или создание нового функционала.

[Beast-L]

Цитата:

Сообщение от Владимир Максимов

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

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

Вот и оцените, какие трудозатраты будут выше: допиливание ранее сделанного функционала или создание нового функционала.

Ну а если просто сбрасывать дату в серверную и не восстанавливать при переходе обратно?

Ведь основная цель - не дать пользователю внести данные задним числом в той компании где ему это делать не позволено.

[3oppo]

Сколько у вас таких пользователей? Если их меньше 20 то создайте двух разных юзеров для двух разных компаний, одному разрешите менять дату другому нет, вот и вся проблема! Так будет намного правильней, и логичней, чем «городить огород» на период внедрения. Не вижу не каких проблем в том, что бы когда пользователь собрался вводить исторические данные, он взял бы и зашел под другим именем.

[Beast-L]

Цитата:

Сообщение от 3oppo

Сколько у вас таких пользователей? Если их меньше 20 то создайте двух разных юзеров для двух разных компаний, одному разрешите менять дату другому нет, вот и вся проблема! Так будет намного правильней, и логичней, чем «городить огород» на период внедрения. Не вижу не каких проблем в том, что бы когда пользователь собрался вводить исторические данные, он взял бы и зашел под другим именем.

Предлагал такой вариант, но было отказано по той простой причине что пользователей 470 это только пока.

[George Nordic]

А теперь обратите внимание, что в 5ке (Microsoft Dynamics AX 2009) будет кардинально переделана работа с временем и датами. Дата и время - только из 1 точки: сервера базы данных, т.к. к нему цепляется множество АОСов, которые могут находиться в разных часовых поясах. Время - по UMT, а уже на клиенте будет отбражено в соответствии с часовым поясом и настройками клиенты.

Подумайте, если будете со временем мигрировать на 5+.

С Уважением,
Георгий

[Beast-L]

Цитата:

Сообщение от George Nordic

А теперь обратите внимание, что в 5ке (Microsoft Dynamics AX 2009) будет кардинально переделана работа с временем и датами. Дата и время - только из 1 точки: сервера базы данных, т.к. к нему цепляется множество АОСов, которые могут находиться в разных часовых поясах. Время - по UMT, а уже на клиенте будет отбражено в соответствии с часовым поясом и настройками клиенты.

Подумайте, если будете со временем мигрировать на 5+.

С Уважением,
Георгий

Когдато будем обязательно. Спасибо учтём!

[Beast-L]

Кому всётаки интересно решение:

\Classes\Application\setDefaultCompany

......................................................................
    }

    #define.WarnFlag(0x08)

    if (dialog && new Session().clientKind() != ClientType::COMObject)
    {
        if (thisCompany != _selectableDataArea)
        {
            if (!cache.get(classstr(info), identifierstr(Autologoff), false))
            {
                select userInfo
                    where userInfo.id == curUserId();

                if (userInfo && userInfo.generalInfo & #warnFlag)
                    warning(strFmt("@SYS53441", _selectableDataArea));

            }
        }
    }

    if(SecurityKeySet::getMenuItemAccess(menuitemdisplaystr(SystemDate), MenuItemType::Display) <= AccessType::View)
    {
        if(getServerDate() != systemdateget())
        {
            warning(strfmt("Дата изменена с %1 на %2", systemdateget(), getServerDate()));

            systemdateset(getServerDate());
        }
    }

    inventDim::findOrCreateBlank();

........................................

\Forms\SystemDate\Methods\init

void init()
{
    ;

    if(SecurityKeySet::getMenuItemAccess(menuitemdisplaystr(SystemDate), MenuItemType::Display) == AccessType::NoAccess)
    {
        throw error("Нет прав для этой операции");
    }

    super();

    machineDate.dateValue(today());
    machineTime.value(timenow());

    systemDateOrig = systemdateget();
    newDate.dateValue(systemDateOrig);

    if(SecurityKeySet::getMenuItemAccess(menuitemdisplaystr(SystemDate), MenuItemType::Display) == AccessType::View)
    {
        NewDate.allowEdit(false);
    }
}

Пока что лучше не нашлось.