Local do banco de dados do campo da lista de tarefas alterado de 2007 para 2010
Pergunta
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
- 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.
- 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).
- 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.
Solução
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.