Para evitar erros na operação do sistema, as janelas de configurações do sistema e de usuários devem ser modais, ou seja, quando alguma delas estiver aberta o usuário não poderá abrir mais nenhuma outra janela, até elas serem fechadas.

Telas que devem ser modais:
definicoes_aplicativo.py
gerenciamento_permissoes.py
meu_usuario.py
criar_usuario.py

Há duas imagens dentro da pasta images:

• logo_farmacia_cotolengo.svg
• logo_farmacia_cotolengo_sem_escrita.svg

Elas devem ser renomeadas para:

• logo_tela_principal.svg
• logo_sem_escrita.svg

Usando um nome mais genérico, fica mais prático e faz mais sentido para outras instituições que queiram fazer uso do código substituir esses arquivos por suas próprias imagens, sem precisar manter o nome 'Cotolengo' nelas ou precisar alterar os arquivos glade para mencionar o novo nome das imagens.

Além da criação de usuários e aplicação de permissões de acesso individuais, seria interessante ter uma lista de perfis de usuário com acessos pré-definidos para determinados módulos.
Perfis como por exemplo 'administrador', 'farmacêutico', 'cadastrador', 'apenas visualização', etc., todos eles contendo um conjunto de acessos diferentes.
Os usuários cadastrados poderiam então ser associados a esses perfis e herdarem todos os acessos do perfil.
Ao alterar algum acesso do usuário que esteja associado a um perfil, esse usuário deixa de fazer parte do perfil específico e entra no perfil 'personalizado'.

Hoje há vários grupos de valores a ser incluídos na tela definicoes_aplicativo.py.
Os grupos consistem de um campo de entrada, um botão de inclusão, uma lista de item já inclusos e um botão de remover para remoção de um item selecionado na lista.
Eles se apresentam lado a lado sem muita distinção de onde começam e terminam.
Seria bom se tivessem alguma forma de destaque.

Possibilidades:

• cada grupo possuir uma cor de fundo única; pros: ok; contras: fora de padrão.
• cada grupo ficar dentro de um expander; pros: ficam todos escondidos; contras: não há destaque se todos estiverem expandidos;
• cada grupo em uma aba de um notebook; pros: reduz o scroll da página; contras: talvez não caiba todas as abas em um único notebook;
• cada grupo estar em um groupbox; pros: ok; contras: quanto mais grupos, mais longo o scroll da página.

Telas que contenham listas de items cadastrados devem possuir um comportamento singleton, ou seja, quando uma dessas janelas estiverem abertas, mesmo que o usuário tente abrir uma outra instância do mesmo objeto, somente o atual deverá permanecer aberto, não criando assim uma segunda tela idêntica.

Esse comportamento tem como objetivo evitar erros na operação no sistema, por exemplo se o usuário cadastrar um item em uma janela e o item não ser listado na outra, gerando confusão ou duplicação de items caso ele decida cadastrar o mesmo item novamente para ter certeza que o fez.

Esse comportamento deverá ser aplicado às seguintes telas:
cadastro de moradores
cadastro de medicamentos
criação de análises de prescrição
abrir análises de prescrição
abrir esclarecimentos
abrir intervenções

Observação: janelas singletons não devem ser modais, elas continuarão permitindo que o usuário manipule outras janelas do sistema, desde que não sejam janelas de configurações, pois essas deverão ser modais de acordo com o issue #11 .

Tive problemas em criar o ambiente de desenvolvimento no Windows pois o código não encontrava o caminho para a pasta GLADE e IMAGENS. No Linux funciona perfeitamente.
Portanto, para referenciar arquivos GLADE e IMAGENS mais facilmente, o melhor seria movê-los para dentro da pasta SRC.
Isso requer algum esforço pois é necessário renomear os caminhos dentro dos códigos-fonte e, possivelmente, o caminho para as imagens de dentro dos arquivos GLADE.

Baixa prioridade.

Adicionar na tela definicoes_aplicativo.py um grupo de radiobuttons para selecionar entre paciente ou morador.
Se escolher morador, todas as opções atuais continuam as mesmas: moradores possuem lares.
Se escolher paciente, uma nova tela deverá ser criada para visualização e inclusão do cadastro, em uma nova coleção no banco, pois pacientes possuem endereço completo e possivelmente outros campos importantes e únicos, como CPF por exemplo.

Todas as demais telas que fazem uso de moradores deverão também ler as informações de pacientes.

Outras configurações, como cadastro de lares, provavelmente deverão ficar escondidas caso a opção 'paciente' seja escolhida.

No menu deverá haver 2 items diferentes para cadastro de cada um, podendo ser ambos habilitados, mas somente 1 será de fato utilizado na abertura de análises da prescrição.

Se a opção escolhida é a de não mostrar os items do menu caso o usuário não tenha permissão de acesso a eles, quando todos os items desse menu forem removidos, o próprio menu também deve ser removido para evitar painéis vazios.

Esssa é uma opção na tela definicoes_aplicativo.py que afetará somente a tela base_module.py.

A opção em definições do aplicativo é:
Módulos e itens do menu sem permissão para o usuário devem ser: Removidos

Exemplo:
O menu "Visualizar" possui 2 items: "Dados por Lar" e "Dados Totais".
Se o usuário não possuir permissão de acesso a "Dados por Lar" nem a "Dados Totais", o menu "Visualizar" não deve ser mostrado também, ou seja, deve ser removido.

Todas as mensagens que são armazenadas nas statusbar de cada tela devem possuir o nome do usuário logado no sistema, data e hora que a mensagem foi criada.

Ex.:

Gidalti - 22/01/2017 às 08:16 - Não foi possível a conexão com o banco de dados.

Essa é uma melhoria que deverá ser encerrada assim que a implementação for feita nas telas já existentes. Não deverá continuar aberta após isso, pois já se tornará parte integrante das especificações de design do projeto.

Criar documentação de utilização do programa para todos os módulos que farão parte do milestone 'versão 1.0'.
No primeiro momento não será abordada a documentação para desenvolvedores, somente para usuários finais.
A documentação deverá ser feita na Wiki do Github, escrita em português, contendo o maior número de screenshots possível para maior elucidação.

A tela de login deverá ter uma opção de alterar o endereço do banco de dados e credenciais, para que seja possível configurar o acesso ao banco de dados sem ser necessário alterar o código fonte.
As informações podem ser escritas em um arquivo texto ou um banco de dados local, como por exemplo Sqlite3.
Alguma lógica terá de ser implementada e até mesmo alterada, pois hoje a conexão com o banco de dados é verificada ao abrir a tela de Login, e isso deve ser mudado para ser verificada somente ao pressionar o botão 'Logar', se sucesso proceder, se falhar retornar uma mensagem de erro que poderá ser mostrada na statusbar.

Implementar na tela de gerenciamento de permissões diferentes níveis de acesso por operações no banco de dados, ou relacionados (CRUD - create, read, update, delete; como nada é deletado, a inativação de um item do cadastro poderia ser um dos níveis de acesso).
Todos os objetos que dependem de permissões de acesso deverão também ser alterados.
Isso tornaria todo o processo mais seguro, pois além de impedir que usuários sem permissão acessem a determinadas telas, possibilitaria que o acesso seja possível, mas algumas operações, como criar ou atualizar uma entrada no cadastro, sejam bloqueadas.
Também facilitaria o controle de outras telas que abrem o mesmo cadastro, como visualizar intervenções, que pode ser acessada pela tela 'abrir intervenções', mas também por 'abrir análise de prescrição'.
Outra regra possível é que a ação de visualizar seja pai de todas as outras, pois se não é possível ler, automaticamente já é descartado a possibilidade de criar e atualizar.
Inativar um item, por ser na verdade uma ação de atualização, talvez não deva ser incluída como um nível extra.

Ex.:
[ ] cadastrar medicamento \Possibilidade de abrir a tela
[ ] visualizar medicamento \Ver a lista de medicamentos, caso contrário ela fica vazia
[ ] incluir novo medicamento \Poder incluir um item, senão o botão 'incluir' fica inativo
[ ] atualizar medicamento cadastrado \o botão 'atualizar' fica inativo ou não
[ ] inativar medicamento \a flag 'ativo' fica em modo somente-leitura

Outra possibilidade:
[ ] Visualizar medicamentos \Permissão de acessar o cadastro de medicamentos
[ ] incluir medicamentos \Permissão de incluir medicamentos pelo cadastro ou qualquer outro lugar, caso contrário o botão 'incluir' fica inativo
[ ] atualizar medicamentos \Permissão de atualizar os medicamentos pelo cadastro ou qualquer outro lugar, incluindo a flag 'ativo', caso contrário o botão 'atualizar' fica inativo

Ainda assim, mais uma possibilidade seria o controle de ações tela por tela, ou seja, eu poderia permitir a atualização de uma intervenção pela tela 'abrir análise de prescrição' mas não permitir pela tela 'abrir intervenções'. Ficaria muito mais longa a lista de permissões, mas ao mesmo tempo daria muito mais controle no fluxo de trabalho do usuário.

Por fim, é necessário balancear se a prioridade é controle do fluxo de trabalho ou das operações com o banco de dados. Impedir o usuário de alterar dados ou de acessar telas?

Alterar o texto sobre a logo para conter apenas "Farmácia-Clínica".
No desenho, remover a parte branca onde contém o logo do Cotolengo.

Salvar a imagem atual fora do projeto no Github para a entrega para o Pequeno Cotolengo.

Há algumas telas do sistema que não está de acordo com o nome do código fonte, criando uma situação onde o nome da janela ou do ícone na área de trabalho difere do título da tela oficial nos labels, mostrado dentro da área de desenho da janela.

Por exemplo:
Código fonte: meu_usuário.py
Arquivo glade: tela_meu_usuario.glade

• propriedade nome da tela: Meu Usuário

<property name="title" translatable="yes">Meu Usuário</property>

• texto da label na tela: Meus Dados

<property name="label" translatable="yes">Meus Dados</property>

Solução proposta: padronizar o nome do arquivo e da classe no código fonte, nome da tela e label de título no arquivo glade, todos iguais ou o mais parecido possível dentro das melhores práticas de nomenclatura para cada objeto.

Se um usuário possui acesso a um conjunto de módulos personalizado e um novo usuário precisa ser adicionado ao sistema possuindo exatamente as mesmas permissões, o sistema poderia facilitar essa cópia por meio de alguma implementação na tela de gerenciamento de permissões.

Baixa prioridade.