ACL. Зависимость типа от очереди

[Стас]

Доброго времени суток!

Разбираюсь с ACL-ами. Поигрался с примерами из мана, по отключению кнопок и статусов и т.п. Вроде понятно. Теперь боевая задача: При создании тикета агентом, при выборе очереди "Fair Ideas", нужно убрать все возможные типы кроме "Idea". Сделал вот так:

https://drive.google.com/file/d/0BwAfmY ... sp=sharing

Это работает, но только с уже существующими и находящимися в очереди "Fair Ideas" тикетами, и только при редактировании "Свободных полей". А надо что бы работало при создании "новой заявки по телефону". Не понятно. Ковыряем ман и форум дальше... Находим кусок

Код: Выделить всё

Frontend => {
            Action => ['AgentTicketPhone', 'AgentTicketEmail'],
        },

Вроде то что надо! Создаем новый, аналогичный первому, ACL:

https://drive.google.com/file/d/0BwAfmY ... sp=sharing

Совсем не работает. Совсем не понятно. (( По логике вроде бы все правильно делаю. Если логику правильно понимаю. В чем может быть причина?
При проверке каждого нового ACL'а, другие отключаю.
Можно сделать и на оборот, при выборе типа "Idea", оставлять доступной только очередь "Fair Ideas", но хочу сделать так, что бы в других очередях данный тип вообще не был доступен.
ACL зависимости доступного списка очередей от типа заявки работает на ура.
В интерфейсе клиента вообще не получается ни какие ACL'ы реализовать. (( Выбор типа заявки у костомеров отключен в принципе. По дефолту - "Инцидент", но с помощью планировщика сделал по тригеру "TicketCreate", проверять, не назначена ли тикету очередь "Fair Ideas", и если да, то автоматом меняет тип на "Idea". И большинство заявок будет поступать в очередь "Fair Ideas" именно через вэб-интерфейс кастомеров или по почте. А агенты редко будут в эту очередь заявки регистрировать, и вот что бы агенты не запутались в таких редких случаях, и не нафигачили чего не надо нафигачивать, необходимо по максимуму все ACLами подрезать.

В общем, в данную задачу можно все решить обходными пуятми...

Что то я много все в кучу свалил. Краткость не моя сестра, извините )) Попробую уточнить вопросы:
1. Почему не работает ACL в "новая телефонная заявка"(второй скрин)? Чего-то не хватает, но не пойму чего. Вроде бы простая задача
2. Почуму не работает зависимость типа от выбранной очереди? С этим надо обязательно, для ршенеия если не этой задачи, то будущих.
3. Почему не работает ACL в интерфейсе кастомера? Хотя, с костомерским ACL'ом еще не разбирался.

Как всегда буду благодарен даже пинкам в правильном направлении.

[alexus]

Попробуйте вот такой формат

Снимок экрана 2015-08-27 в 19.00.57.png (62.45 КБ) 11429 просмотров

[ykolesnikov]

А что значит - не работает? Ваш ACL2 предполагает, что при выборе очереди, указанной в ACL, ограничивается набор значений для выбора значений в поле TYPE. Есть, правда, сомнение у меня в том, что в форме телефонной заявки, поле Type расположено выше поля Очередь и, следовательно нарушается логика - значение верхнего поля зависит от значения указываемого в поле нижнтего расположеного. Могу и ошибаться.

[Стас]

Алексей, не работает ((

А что значит - не работает? Ваш ACL2 предполагает, что при выборе очереди, указанной в ACL, ограничивается набор значений для выбора значений в поле TYPE.

Да, хочу именно так, и оно не работает.

Есть, правда, сомнение у меня в том, что в форме телефонной заявки, поле Type расположено выше поля Очередь

Да, Тип выше Очереди.

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

Юрий, была такая мысль, но ведь когда выбираешь очередь, возле поля "Тип"(и других) справа крутится, даже не знаю как назвать, пусть будет колесико обновления статуса, думаю Вы поняли о чем я, и раз так, то идет какая-то проверка каких-то условий. Полагаю что условий ACL в том числе. Иначе, если есть только прямая зависимость нижних полей от верхних, то зачем тогда что-то проверять в верхних при изменении нижних??

[ykolesnikov]

Про индикаторы обновления полей говорить не буду, на быстрых ПК их можно и не заметить, но обычную человеческую логику отменять не надо! Вводить очередь в поле ниже типа, а потом возвращаться вверх для ввода типа, в этом есть что-то ненормальное. У меня работают ACL для выбора категории заявки (динамическое поле) в зависимости от Типа. Расположены они, естественно в логической последовательности.
Здесь, для категории используются коды, не обращайте внимания, (это тяжелое наследие постижения истины четырехлетней давности, на экране подставляется перевод из файла ru_custom.pm).

image.jpg (289.05 КБ) 11408 просмотров

[alexus]

Алексей, не работает ((

Всё работает - см скриншот. Вы применили ACL? Он действительный? Другие ACL не перекрывают его?

Снимок экрана 2015-08-28 в 9.51.41.png (133.28 КБ) 11405 просмотров

[Стас]

Юрий, я с Вами согласен. Но..
Есть две логики - Человеческая и Машинная. Чаловеческая может быть правильной, не правильной или альтернативной(как вариант). Машинная существует в единственном экземпляряре. Все либо работает в соответсвии с ней, либо не работает совсем. Ваша, - правильная. Но работает ли ОТРС в соответсвии с ней, вот в чем вопрос, и можно ли реализовать, без кастома, альтернативную(мою ) логику? Алексей вот говорит что можно. У меня упорно не выходит, но об этом ниже.
Можно коечно, сказать агентам что все работает вот так и ни как иначе, но если бы все они были мне подченены и за каждый косяк можно было их бить по головам. Ах, если бы Но агенты, которые будут работать с очередью Fair Ideas - даже не IT-шники, и люди, скажем так "творческие" в вопросах касающихся IT и автоматизированных систем в целом, если будут возможности что то сделать не правильно, они сделают не правильно. Не в 100% случаев конечно же, но все же. В связи с чем хочется отсавить им как можно меньше возможностей для "творчества".

Алексей, я не сомневаюсь что у Вас все работает. Но у меня - нет. Может я не вижу чего то очевидного? уже Раз 10 переделывал этот ACL. В том числе и с нуля. И добавлял PossibleNot с указанием типов которые не нужны.
И да, первое что я понял разбираясь в ACL-ах, то это то, что новый ACL нужно не забывать синхронизировать переведя его в статус "действительный", завдать ему имя ,которое будет первым в списке, ставить галку "прекратить провреку при совпадении". Ну и что б наверняка - остальные ACL'ы сделать не дествительными. И еще раз синхронизировать

[alexus]

1. По поводу логики
Задача стоит с том, чтобы создать что-то именно в целевой очереди? Это очевидная ошибка логики. Очередь - это группа людей, которая обрабатывает тикет. Совершенно очевидно, любой, даже самый не ИТшный, творческий человек при регистрации идеи должен иметь возможность выбрать тип запроса - ИДЕЯ - и сделать некое описание этой идеи. И ему совершенно всё равно, ГДЕ будет обрабатываться данный тикет.
И вообще у меня смутные подозрения, что идеи ваши надо регистрировать не в агентском интерфейсе, а на клиентском портале. Мне кажется Вы просто вообще не представляете реальную бизнес-задачу, и не понимаете, как её решать - методически и технически.

2. По поводу "не работает"
Вы не можете списать правильно ACL с приведённого скрина - ничем не могу помочь!

[Стас]

1. По поводу логики
И ему совершенно всё равно, ГДЕ будет обрабатываться данный тикет.

Это как?

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

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

2. По поводу "не работает"
Вы не можете списать правильно ACL с приведённого скрина - ничем не могу помочь!

Да. Бывает что не могу. По этому ели что то не получается делаю с самого начала. И несколько раз если надо. А еще могу не тот скрин прикрепить. Извините. Но раз уже скомпрометировал себя, думаю не стоит прикреплять "правильный", который все равно не работает. Отложу пока этот вопрос. Потом свежим взглядом посмотрю. Может где то все равно не правильно списал, зачем позориться да и время тратить Ваше.

В любом случае, спасибо за Ваши с Юрием ответы.

[alexus]

В ACL надо писать так - Properties - Ticket (а не Type!!!) - Queue - Имя очереди
По поводу логики, очередей, сервисов и клиентского портала я неоднократно писал на форуме, поищите....

[Nik0n]

В ACL надо писать так - Properties - Ticket (а не Type!!!) - Queue - Имя очереди

Когда в Properties "Имя очереди" русскими буквами то ACL работает.
Когда нужно указать "Имя очереди" в Possible - то ACL работает только когда "Имя очереди" латиницей.
До этого допер спустя часа два (ведь в Properties - работает).
ЧЯДНТ ?

[ykolesnikov]

Если возможно, я бы писал QueueID. Тогда, при необходимости, можно и имя очереди менять как угодно, а ACL менять не придется. Но надо пробовать, не всезде это возможно

[Nik0n]

Судя по доке Example 5.7. Reference showing all possible important ACL settings.
В Possible только Queue - а значит только имя.

[ykolesnikov]

Не знаю, у меня очереди с кириллицей в ACL используются и работают.
Пример: (выгружено в YML)

Код: Выделить всё

Possible:
      Ticket:
        Queue:
        - ОТП::Терр_КУИ_ЖУ_ОРСП на Строит.4а
        - Общая
    PossibleNot: {}
  ConfigMatch:
    Properties:
      CustomerUser:
        Group_rw:
        - CustCUI
      Frontend:
        Action:
        - CustomerTicketMessage

[Nik0n]

Обновился до 5.0.9 - заработало в Possible кирилицей.