Updates from richieri RSS Toggle Comment Threads | Keyboard Shortcuts

  • richieri 20:23 on 08/02/2012 Permalink | Reply
    Tags: approval, aprovação, decisão, decision, , , , service desk, workflows   

    Um jeito de criar um workflow de aprovação no OTRS 

    Workflows de aprovação podem ser criados de diferentes maneiras no OTRS, principalmente quando você trabalha com o módulo de gerenciamento de mudanças.

    Há uma maneira um pouco mais simples de se trabalhar com aprovações utilizando o apenas o módulo de gerenciamento de Incidentes e Problemas (ITSMIncidentProblemManagement).

    Ao instalar o pacote ITSMIncidentProblemManagement, você visualizará um link “Decision” nos tickets. Obviamente há algumas configurações a serem feitas para que este link apareça apenas para decisores. Isto também pode ser feito de diversas maneiras também!

    Mas gostaria de compartilhar uma maneira de construir um fluxo de aprovações utilizando filas. Desenhei isto para um cliente estes dias e parece eficaz.

    O conceito

    Temos uma central de atendimento que atende uma fila chamada “Central”. Esta equipe recebe todos os chamados da empresa e se encarrega de resolve-los em primeiro nível quando possível, solicitar aprovações quando necessário ou encaminhar para um dos possíveis grupos especialistas de 2o ou 3o nível da empresa se não conseguir resolver em primeira instância.

    Criamos então uma fila para cada aprovador. Por exemplo, podemos ter uma ou mais pessoas responsáveis por aprovar solicitações de TI, e outras pessoas responsáveis por aprovar solicitações de RH.

    Temos no OTRS então algumas filas. Por exemplo:

    • Central (Central de atendimento Nível 1)
    • Solicitar Aprovação
      • Aprovadores TI
      • Aprovadores RH
    • Suporte Especialista Infraestrutura
    • Suporte Especialista Aplicações

    Quando a Central de atendimento identifica que uma solicitação precisa de aprovação de um gestor da área de TI, ela encaminha esta solicitação para a fila “Aprovadores TI”.

    O gestor da área por sua vez aprova este chamado e reencaminha o mesmo para a Central novamente.

    Como exibir o link Decision apenas para os aprovadores?

    Os aprovadores estarão cadastrados nos grupos aprovadoresti e aprovadoresrh.

    Acesse o SysConfig e acesse Ticket -> Frontend::Agent::Ticket::MenuModule

    Encontre o parâmetro Ticket::Frontend::MenuModule###420-Decision adicione uma chave Group com o conteúdo “rw:aprovadoresti;rw:aprovadoresrh” sem aspas.

    Pronto!

    Melhorando a vida do Gestor

    Para facilitar um pouco a vida do gestor, criei um módulo que move o chamado automaticamente para um fila especificada pelo administrador do sistema. Neste nosso exemplo, o ticket seria movido automaticamente para a fila Central novamente após a aprovação do gestor, podendo inclusive ir com um status diferenciado.

    Você pode fazer o download deste módulo aqui.

    Após instalar este módulo, faças as configurações necessárias no Sysconfig -> Ticket -> Frontend::Agent::Ticket::ViewDecisionMove

    Outras maneiras


    O OTRS é uma ferramenta que necessita de uma documentação mais clara em alguns pontos. Portanto, se você trabalha de outra maneira com aprovações dentro dele, por favor, compartilhe com a gente :)
     
  • richieri 18:41 on 02/02/2012 Permalink | Reply
    Tags: authentication, customer, customerauth, joomla, , single sign on, sso   

    Login automático entre Joomla e a interface de cliente do OTRS 

    Acabo de desenvolver a minha primeira versão do módulo Kernel::System::CustomerAuth::JoomlaSSO.

    Com ele, usuário logados no Joomla, acessam diretamente a interface de cliente do OTRS sem a necessidade de digitar usuário e senha. O base de clientes do OTRS deve ser a mesma do Joomla.

    Algumas modificações são necessárias no Joomla e no OTRS, por isso ainda não é um modulo fácil de instalar.

    Se você possuir interessante em fazer esta integração em sua instalação, fale comigo!

     
  • richieri 17:53 on 09/01/2012 Permalink | Reply
    Tags: pages, paginas, post, privado, private   

    WordPress – Posts privados por padrão 

    Este é meu primeiro plugin WordPress hospedado oficialmente lá no wordpress.org:

    http://wordpress.org/extend/plugins/private-post-by-default/

     
    • M Farhan 13:57 on 18/01/2012 Permalink | Reply

      Hello,

      I found your Private posts by default plugin so helpful.
      Now, I want to save the time, when anybody update posts visibility private to public and vice versa.

      Thanks, in advanced.

  • richieri 12:30 on 07/01/2012 Permalink | Reply
    Tags: acl, acls, , ticket   

    OTRS – Listas de Controle de Acessos (Access Control Lists ou ACL’s) 

    As ACL’s servem para incrementar o sistema de permissões do OTRS. Com elas é possível restringir escolhas de atributos do ticket ou ações possíveis de serem tomadas de acordo com as propriedades atuais do mesmo (fila atual, estado etc).

    Atualmente criamos as ACLs com implementação de códigos no arquivo Kernel/Config.pm (recomendado) e não há interface gráfica para isso. Com sua utilização, é possível inclusive implementar pequenos workflows no sistema.

    Vejamos um exemplo de ACL que restringe um chamado de prioridade alta (5) para que seja permitido move-lo apenas para uma fila chamada Alerta:

    # ticket acl
    $Self->{TicketAcl}->{'ACL-Nome-2'} = {
      # match properties
      Properties => {
        # current ticket match properties
        Ticket => {
        Queue => ['Raw'],
        Priority => ['5 very high'],
        }
      },
      # return possible options (white list)
      Possible => {
        # possible ticket options (white list)
        Ticket => {
          Queue => ['Alerta'],
        },
      },
    };

    Neste exemplo, é bom que se deixe claro que a única ação que restringimos foi a alteração de fila. As outras ações continuam possíveis de acordo com as parametrizações e permissões do usuário. Por exemplo, ainda é possível adicionar notas ao chamado, responde-lo, mudar seu status para qualquer um disponível no sistema.

    É possível notar que existem dois blocos de código neste exemplo acima. O  primeiro com comentário “# match properties” é a definição das propriedades atuais do ticket, como se fosse um filtro onde definimos em que ocasiões essa ACL será aplicada.

    No segundo bloco definimos as restrições ou permissões que os tickets que “cairem” nesta ACL sofrerão.

    Action

    Vamos aprimorar este exemplo fazendo com que um ticket de prioridade 5 não possa ser fechado na fila Raw através da tela “Fechar” (módulo AgenteTicketClose). Ficaria assim:

    # ticket acl
    	$Self->{TicketAcl}->{'ACL-Alerta5'} = {
    	  # match properties
    	  Properties => {
    	    # current ticket match properties
    	    Ticket => {
    	    Queue => ['Raw'],
    	    Priority => ['5 very high'],
    	    }
    	  },
    	  # return possible options (white list)
    	  Possible => {
    	    # possible ticket options (white list)
    	    Ticket => {
    	      Queue => ['Alerta'],
    	    },
    	    Action => {
                  AgentTicketClose => 0,
                },
    	  },
    	};

    Além de restringir a escolha dos atributos dos tickets, podemos definir quais ações (ou telas) poderão ser exibidas ou não ao agente/cliente. Neste exemplo acima, além de permitir apenas que o agente mova este chamado para fila Alerta, também desabilitamos a tela e o botão “Fechar” (módulo AgenteTicketClose). Assim não encorajaremos o atendente a fechar os tickets de prioridade 5 na fila Raw.

    PossibleNot

    No entanto, o atendente da ainda pode encerrar o chamado se este estiver na fila Raw, pois não desabilitamos a escolha os estados “Fechado” com e sem exito, ou seja, ele não verá a tela fechar, mas pode fechar o chamado caso clique em “Chamada telefônica realizada” e escolha um dos estados fechado.

    Vamos simular então uma ACL onde o atendente nunca poderá fechar um chamado se o mesmo estiver na fila Raw com prioridade 5. Ficaria assim:

    # ticket acl
    $Self->{TicketAcl}->{'ACL-Alerta5'} = {
      # match properties
      Properties => {
        # current ticket match properties
        Ticket => {
        Queue => ['Raw'],
        Priority => ['5 very high'],
        }
      },
      # return possible options (white list)
      Possible => {
        # possible ticket options (white list)
        Ticket => {
          Queue => ['Alerta'],
        },
        Action => {
          AgentTicketClose => 0,
        },
      },
      PossibleNot => {
        # possible not ticket options
        Ticket => {
            State => ['closed successful','closed unsuccessful'],
        },
      },
    };

    Notem que adicionamos um terceiro bloco de código, o “PossibleNot”. Ali definimos o que não será possível fazer. Para tentar esclarecer mais:

    • Properties: “Quais chamados ou situações”. No nosso caso, todos os chamados que estiverem na fila Raw com prioridade 5 (Muito Alta)
    • Possible: “É possível apenas isto”! No nosso caso, em relação a mover chamados, restringimos para que seja apenas possível mover para a fila Alerta
    • PossibleNot: “Não é possível apenas isto, o resto pode”! No nosso caso, o atendente poderá escolher todos os estados disponíveis de ticket, menos “Fechado com sucesso” e “Fechado sem sucesso”.
    Expressões Regulares

    Também é possível utilizar expressões regulares. No exemplo abaixo (retirado da documentação oficial), exibimos apenas serviços que comecem com a palavra “Hardware”, para um ticket estiver na fila HW ou uma de suas subfilas:

    $Self->{TicketAcl}->{'Only-Hardware-Services-for-HW-Queues'} = {
           # match properties
            # note we don't have "Ticket => {" because there's no ticket yet
            Properties => {
            Queue => {
                Name => ['[RegExp]HW'],
                }
            },
            # return possible options
            Possible => {
                # possible ticket options
                Ticket => {
                    Service => ['[RegExp]^(Hardware)'],
                },
            },
        };

    Vale a pena lembrar que os serviços começados com a palavra “Hardware” continuaram sendo exibidos em outras filas. Foi utilizando esse tipo de ACL que construí um módulo que permite escolher os serviços que queremos exibir em cada uma das filas do sistema.

     

    Parâmetros possíveis

    Aqui temos uma lista de todos os parâmetros possíveis para as ACLs:

    # ticket acl
        $Self->{TicketAcl}->{'ACL-Name-Test'} = {
            # match properties
            Properties => {
                # current action match properties
                Frontend => {
                    Action => ['AgentTicketPhone', 'AgentTicketEmail'],
                },
                # current user match properties
                User => {
                    Group_rw => [
                        'hotline',
                    ],
                },
                # current user match properties
                Ticket => {
                    Queue => ['Raw'],
                    State => ['new', 'open'],
                    Priority => ['some priority'],
                    Lock => ['lock'],
                    CustomerID => ['some id'],
                    CustomerUserID => ['some id'],
                    TicketFreeKey1 => ['some key'],
                    TicketFreeKey2 => ['some key'],
                    # ...
                    TicketFreeKey8 => ['some key'],
                    TicketFreeText1 => ['some value'],
                    TicketFreeText2 => ['some value'],
                    # ...
                    TicketFreeText8 => ['some value'],
                }
            },
            # return possible options (white list)
            Possible => {
                # possible ticket options (white list)
                Ticket => {
                    Queue => ['Hotline', 'Koordination'],
                    State => => ['some state'],
                    Priority => ['5 very high'],
                    TicketFreeKey1 => ['some key'],
                    TicketFreeKey2 => ['some key'],
                    # ...
                    TicketFreeKey8 => ['some key'],
                    TicketFreeText1 => ['some value'],
                    TicketFreeText2 => ['some value'],
                    # ...
                    TicketFreeText8 => ['some value'],
                },
                # possible action options (white list)
                Action => {
                    AgentTicketLock => 1,
                    AgentTicketZoom => 1,
                    AgentTicketClose => 1,
                    AgentTicketPending => 0,
                    AgentTicketNote => 1,
                    AgentTicketHistory => 0,
                    AgentTicketPriority => 1,
                    AgentTicketFreeText => 0,
                    AgentTicketHistory => 1,
                    AgentTicketCompose => 1,
                    AgentTicketBounce => 1,
                    AgentTicketTicketPrint => 0,
                    AgentTicketForward => 1,
                    AgentTicketTicketLink => 1,
                    AgentTicketPrint => 1,
                    AgentTicketPhone => 1,
                    AgentTicketCustomer => 1,
                    AgentTicketOwner => 0,
                },
            },
            # remove options (black list)
            PossibleNot => {
                # possible ticket options (black list)
                Ticket => {
                    Queue => ['Hotline', 'Koordination'],
                    State => ['closed', 'removed'],
                },
            },
        };

     

    Consulte também:

     
  • richieri 12:02 on 03/01/2012 Permalink | Reply
    Tags: avatar,   

    Avatares do Buddypress em subblogs de um WordPress MU (multisite) 

    Encontrei esta solução para fazer com que avatares locais de um Buddypress sejam exibidos em todos os blogs de um wordpress MU:

    Anyeossays:

    Ok, I just noticed what BP_AVATAR_URL and BP_AVATAR_DIR are setted relative to url and dir of user blog. I reeplaced that code for one what always use the same absolute paths (obtained from WP_CONTENT_URL and WP_CONTENT_DIR) using the global “uploads” directory. Now all avatars are the same in all weblogs.
    If you like to do it edit the file bp-core/bp-core-avatars.php and modify this functions:

    function bp_core_avatar_upload_path() {
    $basedir = WP_CONTENT_DIR.'/uploads';
    return apply_filters( 'bp_core_avatar_upload_path', $basedir );
    }
    function bp_core_avatar_url() {
     $baseurl = WP_CONTENT_URL.'/uploads';
     return apply_filters( 'bp_core_avatar_url', $baseurl );
     }

    Do post:
    http://www.amberweinberg.com/how-to-add-buddypress-avatars-to-wordpress-mu/

     
  • richieri 19:11 on 08/12/2011 Permalink | Reply
    Tags: aberto, estados, fechado, novo, , status   

    OTRS – Status (estados) pré definidos dos Tickets 

    Uma livre tradução do manul do OTRS 3.0:
    http://doc.otrs.org/3.0/en/html/states.html

    O OTRS permite alterar estados de bilhetes pré-definidos e os seus tipos, ou mesmo adicionar novos. Dois atributos são importantes para um estado: o nome do estado e do tipo de estado.

    Os estados padrão do OTRS são: ‘fechado com sucesso’, ‘fechado sem sucesso’, ‘merged’, ‘novo’, ‘aberto’, ‘pendente auto fechamento +’, ‘pendente auto fechamento -’ ‘lembrete de pendente’, e ‘removido’ .

    Novo

    Os bilhetes estão neste estado geralmente quando são criados a partir de e-mails recebidos.
    Comentário Ronaldo: Desta forma os atendentes sabem que este ticket ainda não foi lido, ou seja, nossa empresa ainda não tem conhecimento deste problema.

    Aberto

    Este é o estado padrão de bilhetes atribuídos a filas e agentes.

    Lembrete de pendente

    Quando o tempo determinado no campo “Data de Pendência” for atingido, o dono bilhete/ticket receberá um email de lembrete sobre o bilhete. Se o bilhete não estiver bloqueado, o lembrete será enviado a todos os agentes da fila. Lembrete de bilhetes só serão enviados durante o horário comercial, e são repetidamente enviados a cada 24 horas até que o estado bilhete seja alterada pelo agente. Tempo gasto pelo bilhete neste estado continua a contar para fins de escalonamento.

    Pendente auto fechamento -

    Bilhetes neste status serão definidos como “Fechado sem sucesso” se o tempo de espera determinado em “Data de Pendência” for atingido. Tempo gasto pelo bilhete neste estado continua a contar para fins de escalonamento.

    Pendente auto fechamento +

    Bilhetes neste status serão definidos como “Fechado com sucesso” se o tempo de espera determinado em “Data de Pendência” for atingido. Tempo gasto pelo bilhete neste estado continua a contar para fins de escalonamento.

    Merged

    Este é o estado de bilhetes que foram fundidos com outros bilhetes.

    Fechado com sucesso

    Este é o estado final de bilhetes que foram resolvidos com êxito. Dependendo da configuração, você pode ou não ser capaz de reabrir bilhetes fechado.

    Fechado sem sucesso

    Este é o estado final de bilhetes que não foram resolvidos com êxito. Dependendo da configuração, você pode ou não ser capaz de reabrir bilhetes fechado.

     
    • Álvaro 13:55 on 06/01/2012 Permalink | Reply

      Ronaldo,

      Gostaria de tirar duas dúvidas:

      1 – Quando colocamos o ticket com o estado merged, o OTRS pede para referenciar a qual ticket ele será vinculado? Nesse caso, o ticket associado também ficará na situação merged? Quando encerramos um ticket merged, ele fechará os demais?

      2 – Há como criar um estado que não seja contabilizado o tempo do mesmo para fins de relatório? Ex: Colocar o estado no ticket Ag. usuário, já que não depende do atendente mais e sim do usuário.

      Desde já agradeço o retorno.

      • Ronaldo 10:10 on 10/01/2012 Permalink | Reply

        1 – Existem associações diferentes. O ticket pode ser pai, irmão ou filho de um outro ticket. Fechando o ticket pai, todos os filhos se fecham!

        • Álvaro 13:30 on 12/01/2012 Permalink | Reply

          Ronaldo,

          Testei aqui associando como pai e filho ou dividindo e quando eu fecho o pai, ele não está fechando os filhos.
          Você teria alguma explicação para isso?

          Desde já agradeço seu retorno.
          abs

      • Ronaldo Richieri 10:24 on 10/01/2012 Permalink | Reply

        2 – Na instalação padrão não. O OTRS Group vende uma solução que permite isso.. mas custa meio caro se sua empresa for pequena. Para médias e grandes, vale a pena.
        Ou podemos desenvolver também. :)

  • richieri 16:38 on 30/11/2011 Permalink | Reply
    Tags: aniversário   

    Meu 29° aniversário! 

    (publiquei isso no dia 29/11/2011 no Facebook)
    To pensando que daqui a pouco faço 29 anos :) Me despeço dos 28 com saudade, mas com a certeza e a alegria de ter vivido intensamente cada dos 365 dias que o compuseram :)

    Reconquistei minha autonomia, me diverti em centenas de forrós e festas que participei e animei, amei demasiadamente, conheci o recife, a Europa, a Africa! Fiz muitos amigos e ouvi muita música boa.

    Vi meus amigos com quem trabalhei por anos (e outros) fazerem sucesso e vi minha carreira profissional deslanchar também!

    Cresci muito como músico, vi o Forró Euzébio crescer muito também!

    Minha família se uniu mais ainda! Ganhei uma nova família querida com a Débora Corcovia! Minha família espiritual, no Daime, também cresceu e se fortificou mais ainda através da união conquistada durante este período.

    Agradeço a Deus e a todos vocês meus amigos e amigas que me proporcionaram um ano de vida tão especial e me entregaram este presente momento, onde posso compartilhar com tanta alegria, a gratidão de estar recebendo meus 29 anos de idade, como um conta gotas diário de belas narrativas e histórias pra contar e cantar por mais dezenas e dezenas de anos =D

    Obrigado!

     
  • richieri 16:42 on 27/10/2011 Permalink | Reply
    Tags: android, atrix,   

    Acesse o OTRS com seu Android 

    Muita gente pediu:

    https://otrsteam.ideascale.com/a/dtd/App-for-mobile-devices-like-Android–Blackberry/83263-10369

    Um desenvolvedor mandou ver!

    https://market.android.com/details?id=com.ptitov.megaticket&rdid=com.ptitov.megaticket&rdot=1

     
    • Dilson 17:04 on 15/01/2012 Permalink | Reply

      Recomendo OTRSAndro .
      Bem menos Bugs que o Megaticket. ;)

      • richieri 16:13 on 17/01/2012 Permalink | Reply

        Super dica! Obrigado! Estou testando aqui :)

  • richieri 11:28 on 26/10/2011 Permalink | Reply
    Tags: 10.04 lts, apache2-mpm-itk, hosting, openpanel, ubuntu server, virtual hosts   

    (English) A small Web Hosting with OpenPanel + Ubuntu Server 10.04 LTS + some tricks 

    Desculpe-nos, mas este texto esta apenas disponível em English.

     
    • Reinaldo Silva 10:00 on 09/11/2011 Permalink | Reply

      Ronaldo, bom dia.

      Temos um OTRS instalado que usamos para chamados e ITSM changes, estamos precisando de alguas personalizacoes no sistema, voce faz consultoria ? Estamos em Alphaville-SP

      Att

      Reinaldo

      • richieri 9:37 on 02/12/2011 Permalink | Reply

        Reinaldo! Desculpe pela demora em te responder!

        O meu de notificação do teu comentário no meu blog ficou no spam. Só vi hoje!

        Se precisar ainda, faço modificações sim! Hoje inclusive estou em um cliente em Porto Alegre fazendo isso.

        Mas moro aí do ladinho de Alphaville, em Sorocaba.

        Se ainda precisarem de ajuda, podem entrar em contato comigo, ainda hoje. Meus telefones estão abaixo.

        Abraço!

  • richieri 11:04 on 14/10/2011 Permalink | Reply
    Tags: , permission, sysconfig, ticket menu bar   

    OTRS: Mostrar/ocultar itens no menu do Ticket de acordo com o grupo do usuário 

    O OTRS é uma ferramenta poderosa que oculta muitos de suas possibilidades no código que ainda não está 100% documentado. Essa eu descobri fazendo engenharia reversa no código.

    Imagine que você quer retirar o menu Prioridade do Ticket para os atendentes de 1o nível e deixar apenas visível para supervisores.

    Acesse ADMIN-> Configurações do Sistema -> Ticket -> Frontend::Agent::Ticket::MenuModule

    Em seguida ache o parametro de configuração referente ao item que você deseja ocultar. Neste caso, Ticket::Frontend::MenuModule###300-Priority

    Adicione um chave “Group” e no campo conteúdo coloque “rw:nome_do_grupo_que_tera_acesso”. Para adicionar mais de um grupo, separe por ponto e virgula: “rw:admin;rw:supervisores”

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Powered by Google Talk Widget