Pesquisa:Mobiliza Mboi/Instrumentos
Desenvolvimento
[editar | editar código-fonte]Orientações para o desenvolvimento dos instrumentos
Migração
[editar | editar código-fonte]Internalização das ferramentas para servidores do HMMD
[editar | editar código-fonte]Feito.
Atualização do software para Hubzilla
[editar | editar código-fonte]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 | editar código-fonte]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 | editar código-fonte]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).
Domínio particular
[editar | editar código-fonte]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 | editar código-fonte]Módulos e interfaces
[editar | editar código-fonte]- Alerta de internação
- Resumo de alta
- Geolocalização
- Recompartilhamento
No nível de modelo de dados
[editar | editar código-fonte]- 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 | editar código-fonte]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 | editar código-fonte]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 | editar código-fonte]Primeira iteração (Redmatrix+Ushahidi+Allourideas)