Log/ata das reuniões do projeto do Novo Software Público Brasileiro.
Reunião técnica em 16-06-2014
16 de Junho de 2014, 17:20, por Paulo MeirellesReunião sobre o SIORG
1) O web service traz as unidades de cada órgão?
Órgão, unidade dentre outros níveis. São cerca de 7k, com atualização quinzenal.
2) Qual a abrangência do web service? Cobre as esferar federais, regionais, estaduais e municipais?
Apenas no executivo federal. Em média são 200 a 300 órgaos.
3) O web service traz como informação o sufixo do e-mail dos servidores de cada órgão?
Não traz. Teremos que manter um cadastro.
4) Com que frequência o web service é atualizado?
Em média, diariamente.
5) Quais os formatos suportado pelo web service?
XML e JSON?
Resultado:
- Vamos ter que manter um cadastro de instituição (tanto empresas privadas quanto públicas).
- Definir rotina quinzenal ou mensal para atualizar instituições de acordo com web-service (Delayed Job).
- Caso o órgão do usuário não esteja cadastrado, dar a opção de cadastrar instituição.
- Criar um catálogo de sufixos de e-mail para preencher o combo box de instituições.
- Deixar unidade em campo texto.
- Especificar os campos das instituições. Alguns campos não existem no SIORG (e.g. Faz parte do SISP?)
- Pesquisar órgão com AJAX.
- Cadastro de instituição deve possuir o CNPJ (Atentar-se a se é filiar ou matriz pois muda os dois últimos dígitos do CNPJ). *Talvez a receita federal possua uma bases de cnpj.
- Funcionalidade para reportar instituições com cadastro errados (não é prioridade).
- Para todos os sufixos cadastrados o campo instituição deve ser obrigatório e caso não exista o órgão do usuário ele mesme deve cadastrá-lo, mas terá que informar o CPJ, obrigatoriamente.
- Talvez seja necessário atualizar do webservice as tabelas de usporte ao cadastro de instituições, como (Esfera, Poder, etc..)
Contato: Carlos Eduardo, (61) 2020-1524, carlos.vieira@planejamento.gov.br;
Reunião técnica em 11-06-2014
16 de Junho de 2014, 15:53, por Paulo MeirellesApresentação
- alexandre
- arthur
- camila
- danielbucher
- david_carlos
- kanashiro
- luciano
- macartur
- matheus
- PauloRMM
- marco (Rougeth)
- seocam
- terceiro
#visão geral da arquitetura
colab é:
* proxy reverso que fica na frente de N aplicações; entre elas o noosfero
* centraliza autenticação
* unificação visual
* motor de buscas
* banco de dados de estatisticas
* front-end Mailman
* blog planet
#quais funcionalidades do noosfero e do colab "conflitam"?
Identidade
- Login
- Perfil do usuário
- Cadastro de usuário
- Busca (Colab)
- lucene + apache solr (backend)
- haystack (importaçao de dados)
- UI no colab (django)
- XMPP: Decisão adiada para 3o release
#definição de fronteiras entre colab e noosfero
- Cadastro
- vai ser feito no Noosfero, e gravado no banco do noosfero
- Login
- var ser feito pelo Colab, contra os dados no banco do noosfero
- por enquanto vamos abstrair a migração de usuários da plataf antiga
- Perfil
- Perfil no Noosfero
- colab fornece API para dados de colaboração (estatisticas e outras coisas) + dados de gamificação (badges etc)
- Noosfero exibe informações obtidas desta API.
- links de perfil no colab vão apontar para o Noosfero
- Busca
- Colab vai centralizar busca
- Implementar modelos de busca no colab para conteúdos do Noosfero
- Perfil de usuário/comunidade
- Artigos (conteúdo)
- Comentários
- caixas de busca nas demais ferramentas serão ocultadas
#decisões adiadas
- Não vamos atacar suporte a XMPP por agora (tanto noosfero quanto colab tem xmpp).
- Não vamos utilizar Agregador de Blogs (Planet) do colab por enquasnto