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

Sorry, this entry is only available in Brazilian Portuguese. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

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:

Buddypress avatars on all blogs of wordpress multisite MU

Sorry, this entry is only available in Brazilian Portuguese. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

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/

(Português) OTRS – Status (estados) pré definidos dos Tickets

Sorry, this entry is only available in Brazilian Portuguese. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

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.

(Português) Meu 29° aniversário!

Sorry, this entry is only available in Brazilian Portuguese. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

(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!

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

Hi,

I’m trying Openpanel, a great new opensource tool that helps developers make a complex server tasks with some mouse clicks.

http://www.openpanel.com/

You can create domains, mail accounts, DNS and other stuff in a “Panel” way. You can create user accounts and allow them to create their own domains, emails and vhosts.

I’m trying it on linode

www.linode.com

With Ubuntu Server 10.04 LTS (You can deploy this image from linode dashboard. You have a virtual machine running after 5 min max)

After a successful OpenPanel install, I need to make my users vhosts run as Apache process of their own user. This way, their php and other apps could write under their directories and make some personal stuff, as also it gets better to my administration tasks.

Unfortunately, this feature is not yet implemented (but it’s on the roadmap), so I need to create the followin “hack”:

  • Install a new MPM apache module:
    sudo apt-get install apache2-mpm-itk
  • Write a script that’s create the directives which makes every vhost runs under it’s owner account and put ir under crontab to run every 10 minutes
    sudo pico /opt/apacheexec.sh
    Put the following content on it:
#!/bin/bash
for sites in /home/*/sites/*
do
    user=`echo "${sites}"|cut -d'/' -f 3`
    site=`echo "${sites}"|cut -d'/' -f 5`
    arquivo=`echo "/etc/apache2/openpanel.d/${site}.inc/mpmitkUser"`
    if [ -f $arquivo ]; then
        true
    else
        echo "<IfModule mpm_itk_module>" > $arquivo
        echo "AssignUserId ${user} ${user}" >> $arquivo
        echo "</IfModule>" >> $arquivo
        exec `/usr/sbin/apache2ctl graceful`
    fi
done
  • Then, make it executable
    chmod a+x /opt/apacheexec.sh
  • Finally, put it to run on crontab
    sudo crontab -e -u root
  • Write it:
    */10 * * * * /opt/apacheexec.sh

And we are done!

OTRS: Show/Hide itens on Ticket Menu according to the user group

OTRS is a great software it’s not 100% documentated. I find this tip digging the source code.

Imagine that you want to remove the Priority link from Nav Bar of Level 1 Agente Front end, while he/she is viewing a ticket and you want it to be viewable only for supervisors.

Go to ADMIN-> SysConfig -> Ticket -> Frontend::Agent::Ticket::MenuModule

Then find the parameter you want to hide/remove. In this case, Ticket::Frontend::MenuModule###300-Priority

Add a key called “Group” and the put “rw:group_that_has_access” as the content. To add more groups, separete with “;”. For example: “rw:admin;rw;supervisors”.

links for 2011-09-22