Viva,
Detectei o comportamento abaixo indicado aquando a utilização do Drupal Commons v6.x-1.6.
Ao seleccionar os filtros "Node: Type" e "Organic Groups: Group Types" numa view que tenha uma relação com "Organic groups: Group node" o query gerado pela preview contém algo como:
...
WHERE ((node.type in ('event')) AND (node.status <> 0) AND (node.type in ('og_group_a', 'og_group_b')))
...A 3ª condição não devia ser algo diferente de node.type, uma vez que esta entra em "conflito" com a 1ª?
Depois de dar uma vista de olhos no código fiquei com a sensação que este seria o comportamento expectável (depois de ler os comentários abaixo), mas não encontrei nenhuma razão explícita que o justifique.
project/profiles/drupal_commons/modules/contrib/og/modules/og_views/og_views.views.inc:276-284
<?php
// Pseudofield which actually operates on node.type
$data['og']['type_groups'] = array(
'title' => t('Group types'), // The item it appears as on the UI,
'help' => t('The type of a group (for example, "blog entry", "forum post", "story", etc).'),
'real field' => 'type',
'filter' => array(
'handler' => 'og_views_handler_filter_og_type',
),
);
?>project/profiles/drupal_commons/modules/contrib/og/modules/og_views/includes/og_views_handler_filter_og_type.inc:16-28
<?php
// This is a copy of views_handler_filter_in_operator::query
// We force the table to be 'node' instead of 'og'. There might be cleaner ways to do this.
function query() {
if (empty($this->value)) {
return;
}
$table = $this->query->ensure_table('node');
$placeholder = !empty($this->definition['numeric']) ? '%d' : "'%s'";
$replace = array_fill(0, sizeof($this->value), $placeholder);
$in = ' (' . implode(", ", $replace) . ')';
$this->query->add_where($this->options['group'], "$table.$this->real_field " . $this->operator . $in, $this->value);
}
?>Já alguem se deparou com a mesma situação, ou, que me saiba explicar o porquê de no código estarem a forçar que a tabela utilizada seja a node?
Se substituir 'node' por 'node_og_ancestry' (disponível devido à relação com "Organic groups: Group node") a view funciona como seria de esperar.
Obrigado pela atenção, qualquer comentário sobre este assunto será bem vindo :)
Comments
Tenho pouca experiência com o OG
mas de qualquer forma o grupo orgânico é um tipo de nó. Um grupo é uma instância desse tipo de nó. Donde de facto o grupo é um nó.
Já tive que usar o OG e tive
Já tive que usar o OG e tive que martelá-lo directamente para se adequar ao propósito que pretendia.
Muito sinceramente não fui grande apreciador, mas como disse o António, a parte de um Organic Group ser um nó, permitiu-me um outro grau de complexidade e de manipulação da informação que não teria se tivesse que desenvolver algo específico.
Em relação à query:
...WHERE ((node.type in ('event')) AND (node.status <> 0) AND (node.type in ('og_group_a', 'og_group_b')))
...
que o resultado obtens? O esperado? Porque tens toda a razão, a 3ª clausula vai anular a 1ª, logo tornando a query incorrecta. Não me lembro de me ter deparado com um problema semelhante já que usava as Views (personalizadas) que eram instaladas aquando a instalação do módulo. Se tiveres oportunidade hás-de experimentá-las e verificar se nenhuma serve o teu propósito. Isto porque do que me lembro, algumas até estavam referenciadas no código do módulo.
View utilizada
(Repondo pelo jcsmorais, já que ele está ausente e eu também acompanhei este problema.)
O resultado é 0 registos, claro.
Das Views inicialmente instaladas, a que mais se aproxima do nosso propósito é a View "content_event_calendar".
Mas precisamos de obter Events apenas de alguns tipos de Groups, pelo que ainda precisamos de manipular esta View.
No entanto, basta colocar um filtro pelo tipo de Group e o resultado passa a ser nulo, devido ao problema na query já referido: em vez de aparecer, como esperado, 'node_og_ancestry.type in (...)' aparece 'node.type in (...)'.