[Feature] Include CPF Field

[SteffanoP]

This PR implements a new algorithm to fill {{cpf}} field on the template/model of certificates.

This PR closes #1 .

Implementation

1. It was created a new optional flag (--cpf-enable) to let users choose if they want to include cpf;
   • In case you want to include a CPF, just run the program python --cpf-enable.
2. A function to check if a CPF is valid or not (validate_cpf);
3. Creates an algorithm to fill any {{cpf}} field based on names.txt.
   • It takes any number on names.txt that is valid and establish as a cpf;
   • If a CPF is not valid, not certificate will be generated and a warning will be logged.
   • Change generateCertificate to optionally receive a parameter called cpf.
4. Update the current models/examples to include {{cpf}} field;
5. A few things had to be changed to meet the requirements above.

Developer notes

A question that I had was if we should generate certificate if a cpf is not valid, I've put a #2 (comment) asking that. By now, it currently generates but does not fill the {{cpf}} field.

Also, I haven't implemented any formatter for CPF fields, if you feel that's necessary, please let me know.

Issues found

• When using Full name, the name is including a \n, this will be fixed until the PR is ready to Merge;
  • That was a false negative Issue, due to the fact that the models/examples were not fully prepared for real data, that was worked in dac35af.
• When two names are homonym, only one file will be created, I'm gonna fix that later;
  • Fixed by 8ff4fd4.

[SteffanoP]

I believe this should be addressed by maintainers and specialists

[weltonfelix]

Muito bom Steffano! Como o projeto ainda está bem no começo, ainda estamos arrumando a casa e acabou que fiz o push da feature (11492c6) antes mesmo de ver sua Pull Request.

Em compensação, adicionei você como coautor em um amend, já que a implementação segue o mesmo princípio.

Seria muito massa você adicionar algumas das features que foram implementadas no seu código, como fechar o arquivo antes do processamento (e6c8e9f) e atualizar os arquivos de exemplo para conterem dados reais (3f34a09).

Sobre a validação de dados, creio que não seria algo tão necessário já que o usuário teria em mãos a lista de dados das pessoas. Por enquanto acabaria apenas deixando a geração um pouco mais lenta, mas quem sabe no futuro?!

Mil desculpas pelo ocorrido. Suas contribuições são sempre muito importantes!

[SteffanoP]

Em compensação, adicionei você como coautor em um amend, já que a implementação segue o mesmo princípio.

Opa @weltonfelix, não precisava, vi que sua implementação foi bem mais completinha do que eu estava pensando no projeto.

Seria muito massa você adicionar algumas das features que foram implementadas no seu código, como fechar o arquivo antes do processamento (e6c8e9f) e atualizar os arquivos de exemplo para conterem dados reais (3f34a09).

Quanto a isso, acho que vocês podem implementar durante o desenvolvimento de algumas coisas mais tarde, como por exemplo para resolver a #3.

Sobre a validação de dados, creio que não seria algo tão necessário já que o usuário teria em mãos a lista de dados das pessoas. Por enquanto acabaria apenas deixando a geração um pouco mais lenta, mas quem sabe no futuro?!

Sobre a validação, eu acho importante, pois como se trata de um certificado, um documento que valida algo para alguém, manter esse tipo de verificação pode evitar futuros problemas de certificados com erros desse tipo. Acho que no nível de implementação do que esse repositório pretende, tratar isso como uma flag (--validade-field ou --validate-cpf seja interessante).

Sobre o tempo de processamento, não há um impacto muito grande visto que a complexidade de processamento se mantém em tempo linear.