This year’s Google Summer of Code is slowly coming to an end. I am working on latest steps to complete the project as planned. In the previous blog post, I was writing about the final code polishing of Mailhandler, while the focus of last week (#11) was to improve the overall project documentation. Before the project wrap-up blog post, I am going to write about the real use-cases for Mailhandler.
This blog post summarizes week #11 of the Google Summer of Code 2016 project - Mailhandler. Time flies and it is already the last phase of this year’s Google Summer of Code 2016. The project is not over yet and I would like to update you on the progress I made last week. In the last blog post I was writing about the problems I faced in week 10 and how we decided to do code refactoring instead of UI/UX work. The plan for the last week was to update Mailhandler with the newly introduced changes in Inmail as well as work on new user-interface related issues.
This blog post summarizes week #10 of the Google Summer of Code 2016 project - Mailhandler.
In the last blog post, I was writing about the comment and demo module improvements. This blog post will provide an overview of the work done in the past 7 days. Even though the plan was to work mostly on UI/UX issues we ended up in code refactoring.
During the 8th week of Google Summer of Code 2016, we have started with adding support for posting comments via email. After getting the feedback from my mentors, there was some space to improve proposed solution. The suggestions were accepted and briefly explained below.
Comments in a submodule
As comments are supported through new handler plugin (
MailhandlerComment), we decided to move it into a submodule -
mailhandler_d8_comment. Following this approach, we can avoid too many dependencies on the main module. The submodule features: Inmail config entity that represents the handler, the plugin class and the related test coverage.
The overall test coverage of Mailhandler module has been improved in the week 7 of Google Summer of Code. The plan for the week 8 was to implement feature for posting comments by sending an email.
MailhandlerNode (handler for nodes), we had to create a new config entity:
inmail.handler.mailhandler_comment and a handler plugin class. Since comments will have limited support, during the last weekly meeting with my mentors (Miro and Primoz), we decided not to add more analyzers as proposed first, but rather to move comment specific business logic to
MailhandlerComment Inmail handler plugin.
The coding period of Google Summer of Code 2016 has been continued after midterm evaluation. After splitting the Mailhandler analyzer into more specific and independent analyzers for different parts of an email message (sender, entity type, PGP, body, footer), last week I was working on providing test coverage for those.
The current tests are mostly written as kernel tests because of their speed of execution.
MailhandlerNodeTest represents an integration test for the node handler and tests the whole process of Inmail analyzers and handlers.
Newly written tests:
As usual, Tuesday is the day to update you on the progress of Google Summer of Code 2016 project - Mailhandler.
Last week both mentors and students had to fill Google Summer of Code midterm evaluation. The evaluation happened after 5 weeks of work and consisted of questions about the chosen organization, program, mentors (for students) and students (for mentors).
This is the 5th blog post of the Google Summer of Code 2016 project - Mailhandler.
Implementing authentication and authorization for a mail sender provided an additional layer of security for Mailhandler project. The module was extended to support both PGP signed and unsigned messages.
This blog post summarizes the third week of the Google Summer of Code 2016 project - Mailhandler.
As mentioned in the previous blog post, the Mailhandler prototype for Drupal 8 has been finished. The prototype has already one of the main features implemented - processing mail messages and creating nodes. However, processed messages could be created by anyone which is not really nice for a module aiming to be used in production. To solve this problem, I've been working on user authentication implementation for almost a week.