Local do banco de dados do campo da lista de tarefas alterado de 2007 para 2010

Question

O que eu testemunhei

Acabei de notar algo bastante irritante no SharePoint após uma atualização de 2007 para 2010.

O esquema da lista de tarefas no SharePoint 2007 tinha primeiro o campo 'Atribuído a'.Basicamente, isso significava que o campo 'Assigned To' foi para o campo 'int1' no nível do banco de dados.

No SharePoint 2010, o esquema da lista de tarefas tem o Predecessor primeiro.Adivinhe o que isso significa para novas listas?As colunas Predecessor vão para o campo 'int1' no nível do banco de dados e 'Assigned To' cai em 'int2'.

Alterar a ordem dos campos no tipo de conteúdo da tarefa só ajuda se você usar uma 'lista personalizada em branco' e adicionar o tipo de conteúdo diretamente.Fazer isso ordenará os campos no esquema de lista de acordo com a aparência de 2007!No entanto, a 'definição da lista de tarefas' ignora isso e usa seu próprio esquema como ponto de partida.Para obter uma lista de tarefas usando os mesmos campos de dados subjacentes do SharePoint 2007, você basicamente precisa retrabalhar (remover e adicionar) os tipos/campos de conteúdo na lista, resultando na redefinição do esquema com o tipo de conteúdo reordenado.

Por que isso importa?

Muitos de vocês talvez estejam se perguntando por que eu me importo com os campos SQL, já que não deveria tocá-los, etc.Bem, para ser honesto, eu não deveria me importar, mas a Microsoft me obrigou!!!

Usamos um DataFormWebPart para acumular tarefas incompletas de todos os sites.Criado usando o SharePoint Designer.Várias opções são definidas para os bits recursivos entre sites, mas a principal delas é a consulta CAML e esta parte está causando dor de cabeça.

<Eq>
    <FieldRef Name="AssignedTo" />
    <Value Type="Integer"><UserID Type="Integer"/></Value>
</Eq>

Sabe-se que o filtro acima é baseado em [eu] e funciona, ou seja, para todos os sites criados em 2007!Tarefas em quaisquer novas listas não!... e agora sei que é porque o SQL subjacente gerado está fazendo:

int1 = [id]

...e não:

int1 = [id] or int2 = [id]

Não tenho certeza (ainda) de como o SharePoint cria internamente o SQL, mas posso investigar isso em algum momento, porque obviamente ele precisa transformar o CAML em SQL e, ao fazer isso, usa uma fonte para pesquisar os mapeamentos de campos associados.De qualquer forma, a fonte será diferente com base em listas antigas ou novas.Acontece que desta vez, por qualquer motivo, ele usa o antigo, MAS de qualquer forma, significa que as tarefas atribuídas a mim estão sendo deixadas de fora.Só consigo ver três opções atualmente

1. Crie um script para atualizar todas as listas de tarefas atuais para refletir a nova definição de lista de tarefas.Não é o ideal e não é uma tarefa fácil.
2. A partir de agora, certifique-se de que todas as listas criadas usando o modelo de lista de tarefas sejam modificadas conforme discutido anteriormente (removendo/adicionando CT's e campos).
3. Coloque o filtro em XSLT e sofra performance!

Sei que o número 2 poderia ser modelado, mas o modelo original ainda permaneceria e afastar-se do modelo MS provavelmente seria suscetível a problemas no futuro!!

Isso foi testemunhado por alguém?Eu posto sabendo que realmente não há uma resposta para isso.Apenas sugestões/opiniões.

Answer 1

Bem, depois de passar muito tempo testemunhando o que foi dito acima.Acontece que simplesmente colocar 'AssignedTo' na parte ViewFields da consulta resolveu o problema!

Mesmo que eu não esteja usando o campo para exibição, o problema foi corrigido adicionando-o.Os campos subjacentes ainda são diferentes, mas o SharePoint SABE DISSO, afinal, e a enorme consulta produzida faz referência aos campos corretos por web/lista.

Querida.