Com esta história das Roles dos utilizadores, foi necessário efectuar umas actualizações ao modelo de dados que tinhamos. Aqui fica a nova versão:

Este é mais um ponto de discussão da nossa plataforma. Existem métodos de determinadas classes que devem ser publicos (WebMethod's) mas só podem ser chamados por utilizadores autorizados. Por exemplo:
o método Notify(Message m), que tal como os outros métodos, tb está disponível para o mundo (WebMethod), não deve poder ser chamado por qq utilizador. Apenas por detentores de serviços de notificação. Caso contrário qq utilizador malicioso criava um proxy para para a plataforma e chamava o método Notify(...) fazendo-se passar, por exemplo, pelo serviço de notificação de incêndios...

Para isso vamos ter que inserir um novo conceito na plataforma, e começa por reflectir-se na BD, que é o conceito de Role

Existem vários tipos de Roles, como por exemplo, Administrator, Manager, Teller, ... , em que cada um terá permissões diferentes para executar determinados métodos.

Pontos a focar na próxima reunião:

• Tratamento de Excepções

• Lógica de pesquisas PISNA

Após algum diálogo optámos por remodelar a lógica de pesquisas na PISNA seguindo o seguinte diagrama de classes
Com esta “funcionalidade” acrescida, implementada na camada de negócios da PISNA pretende-se que as aplicações cliente possam criar expressões de pesquisa a base de dados.

• A lógica de pesquisas a implementar não invalida a necessidade de filtrar as expreções pré-pesquisa, para evitar situações de possivel abuso das funcionalidades disponibilisadas pelo SQL server (como comandos shell...).


• schema para validar o formato das notificações dos SN


• “schema” para actualização do diagrama de classes e script sql
  schema + XML para mostrar info de cliente na altura da subscrição


• Separação entre o que é info. Necessária para os SN e info. Necessário para a PISNA na altura da subcrição.