Pesquisa:Mobiliza Mboi/Instrumentos

Desenvolvimento

editar

Orientações para o desenvolvimento dos instrumentos

Migração

editar

Internalização das ferramentas para servidores do HMMD

editar

Feito.

Atualização do software para Hubzilla

editar

Há duas vias possíveis, instalar um novo hub para os novos alertas, clonando apenas as identidades e mantendo o hub antigo pelo tempo necessário, ou migrar todo o conteúdo para um novo hub e desativar imediatamente o hub antigo. A vantagem da segunda via é manter o conteúdo da primeira fase do projeto permanentemente acessível, o que por outro lado não é um objetivo da plataforma.

Em ambos os casos será necessária a atualização prévia das adaptações e módulos desenvolvidos para o projeto.

Clonagem dos canais

editar

Há um plugin que permite a um software (feito em Java) exportar e importar todos os canais de um hub para outro. Isso contudo não transporta arquivos ou fotos. Pela época em que foi desenvolvido, o plugin deve precisar de alguma atualização para funcionar.

https://github.com/kenrestivo/migrator

https://github.com/kenrestivo/migrator-plugin

Clonagem dos conteúdos

editar

Há dois plugins para migrar fotos e arquivos que funcionam, mas é na base um canal/álbum por vez.

https://github.com/redmatrix/hubzilla-addons/tree/master/redfiles

https://github.com/redmatrix/hubzilla-addons/tree/master/redphotos

Ideia para manter um servidor no ar sem que ele incorpore mais conteúdo (pode vir a ser útil).

https://mobiliza.org.br/display/c69e5cfa98612bd746c30d3b9cea22574e25e30f6263569cdb4f472a1b58b08f@hub.vilarejo.pro.br

Domínio particular

editar

Pretendemos também configurar o novo hub sob um domínio particular na rede hubzilla, criando uma rede paralela à rede hubzilla global em termos do diretório.

Adaptações a atualizar

editar

Módulos e interfaces

editar
  • Alerta de internação
  • Resumo de alta
  • Geolocalização
  • Recompartilhamento

No nível de modelo de dados

editar
  • Comunicação entre grupos no envio de um post privado para dois grupos privados (ubs+comunica). Alternativas:
    • Substituir por um grupo único, adicionando os membros comunica aos grupos das ubs (causará problemas adiante)
    • Permitir reencaminhamento múltiplo (primeiro grupo envia pro segundo grupo como "+tagged"), ou "sourcing" de canal privado (primeiro grupo dá permissão de sourcing pro segundo grupo)
  • Acesso a anexos enviados para um grupo (resumos de alta). Alternativas:
    • Grupo clona anexos e substitui na sua versão da mensagem
    • Grupo intermedia download (estilo "mod/sslify.php")

Segurança

editar

As plataformas pelas quais trafegarão comunicações privadas dos profissionais de saúde sobre o cuidado dos pacientes serão protegidas com padrões modernos de segurança: realizando o tráfego de dados pelo Protocolo Seguro de Transferência de Hipertexto (HTTPS); proibindo o tráfego pelo protocolo inseguro (HTTP); garantindo o acesso às informações apenas aos indivíduos endereçados, através de combinação de usuário e senha; implementando a plataforma sobre um sistema operacional Debian da linha estável, com atualizações de segurança; hospedando a plataforma dentro da infra-estrutura de computação em nuvem da Universidade de São Paulo.

Essas medidas buscam resguardar a confidencialidade das informações, conforme indicada pelos profissionais usuários, não apenas com relação a seu trânsito na rede como também no controle remoto e acesso físico dos servidores.

Administração

editar

Além do desenvolvimento das ferramentas, é necessário apoiar a administração do servidor e o funcionamento contínuo dos sistemas. O servidor é um debian linha estável alocado na infra-estrutura de nuvem da Universidade de São Paulo.

Orientações passadas

editar

Primeira iteração (Redmatrix+Ushahidi+Allourideas)