search

gems-uff / sapos

SAPOS main goal is to ease the management of information related to graduate programs such as enrollments, courses, advisement, scholarships, requirements, among others.
http://gems-uff.github.io/sapos/
MIT License
28 stars 14 forks source link

Configurar nome da universidade e do programa #109

Closed braganholo closed 10 years ago

braganholo commented 10 years ago

Nos históricos, boletins e demais relatórios, aparece o nome da universidade e do programa. Isso deveria ser configurável, pois a Engenharia Civil, por exemplo, que já está usando o SAPOS, não pode emitir histórico no nome da Computação.

braganholo commented 10 years ago

É preciso também configurar o nome do curso que aparece no histórico (lá aparece nível + "em Computação". Exemplo: Mestrado em Computação)

leomurta commented 10 years ago

Precisava ver o que de fato é necessário:

braganholo commented 10 years ago

Pelo que notei, sim, pois eles aparecem em locais diferentes e escrito de forma diferente.

JoaoFelipe commented 10 years ago

Para o nome do curso, qual é a melhor opção? 1- Criar variavel geral que sirva para todos os nívels 2- Criar atributo em nível que diga qual é o curso 3- Criar entidade curso, com nome e associar matrícula a essa entidade

Nome da universidade e nome do programa só aparecem no header dos pdfs (acho). Para issue #110, criei/estou criando uma variavel que define tanto o texto do header quanto o logo.

braganholo commented 10 years ago

Acho que criar a entidade curso impacta no sistema todo, pois tudo teria que estar associado ao curso (usuário, professor, matrícula, aluno, etc). Note que isso permitiria que, por exemplo, colocássemos o SAPOS da Civil e o SAPOS da computação numa instância só. Acho que nós já tínhamos chegado à conclusão de que não iríamos por esse caminho.

Acho que a opção dois é mais genéria que a um, e atende a grande parte dos casos. Portanto, meu voto é pela opção 2.

Vanessa

2014-04-16 16:58 GMT-03:00 João Felipe N. Pimentel <notifications@github.com

:

Para o nome do curso, qual é a melhor opção? 1- Criar variavel geral que sirva para todos os nívels 2- Criar atributo em nível que diga qual é o curso 3- Criar entidade curso, com nome e associar matrícula a essa entidade

Nome da universidade e nome do programa só aparecem no header dos pdfs (acho). Para issue #110 https://github.com/gems-uff/sapos/issues/110, criei/estou criando uma variavel que define tanto o texto do header quanto o logo.

— Reply to this email directly or view it on GitHubhttps://github.com/gems-uff/sapos/issues/109#issuecomment-40644751 .

JoaoFelipe commented 10 years ago

Sendo a opção 2, o que é melhor? Ter um campo complemento que armazene "em Computação" ou ter um campo nome do curso que armazene "Mestrado em Computação"? Aliás, será que alterar o nome do nível para "Mestrado em Computação" e tirar o + "em Computação" do histórico não é uma melhor opção do que adicionar um campo novo? Se existirem dois níveis Mestrado (não sei se é possível), mas um for Mestrado em Computação e o outro Mestrado em Algoritmos, acho que ficaria complicado escolher qual é o Mestrado certo. A não ser que mude a representação do nível, o que seria equivalente a alterar o nome

braganholo commented 10 years ago

João, sua mensagem ficou truncada. De qq maneira. acho que usar complementos ou retirar partes de uma string não vai funcionar em todos os casos. Vamos evitar esse tipo de solução. Melhor ter um campo com o nome completo do curso, e outro para o nível.

leomurta commented 10 years ago

João, indo num caminho oposto: queria que vc avaliasse o impacto da opção 3. Nós até então evitamos ela, por ser mais trabalhosa e não trazer um benefício direto para nosso programa de pós. Mas como a sua bolsa é justamente para essa generalização, e como vc é um cara safo em programação, pode ser um bom momento para isso.

Repare que não basta associar programa (a entidade não é curso, mas sim programa) à matrícula. Teria que analisar entidade a entidade para ver qual teria chave estrangeira para programa. Boa parte da configuração seria por programa, e o controle de acesso também (uma pessoa do programa de Engenharia Civil não poderia ver os dados do programa de Computação).

Com essa análise de impacto poderíamos tomar a decisão definitiva sobre incorporar isso ou não.

braganholo commented 10 years ago

Nesse caso, talvez valha a pena colocar em produção essas modificações que vc já fez, para que a Engenharia Civil já possa ir emitindo históricos escolares e usando o sistema mais a fundo. Como a mudança de inclusão do conceito de programa seria muito grande, eles ficariam ainda um bom tempo sem poder emitir históricos (pois os históricos saem como Computação).

leomurta commented 10 years ago

Além disso, se essa inclusão do conceito de Programa realmente se concretize, a migração terá que ser manual. Ou seja, a nossa base poderia ser migrada diretamente, mas precisaríamos fazer um merge na base deles na nossa, com o conceito de programa. Imagino que isso não seria tão complicado. Poderíamos migrar individualmente ambas as bases e depois fazer um dump/load da base deles dentro da nossa.

JoaoFelipe commented 10 years ago

Acho que podemos discutir isso na #34

braganholo commented 10 years ago

Estou fechando essa issue. As pendências dela ficam na #34.