Saltar para o conteúdo

Pesquisa:Mobiliza Mboi/Instrumentos

Fonte: Wikiversidade

Desenvolvimento

[editar | editar código-fonte]

Orientações para o desenvolvimento dos instrumentos

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).

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

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")

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)