Google Summer of Code 2021 ideas
Znuny is a service desk which is based on OTRS 6 ((Community Edition)). It (currently) is 100% compatible with OTRS 6.
| # | Title | Description | Link |
|---|---|---|---|
| 1 | Support for regular expressions in Generic Agent filters | Implement | Link |
| 2 | Support for empty values in Generic Agent filters | Implement | Link |
| 3 | Support for negations in conditions for ticket notifications | Implement | Link |
| 4 | Support for inline text modules | Design & Implement | Link |
| 5 | Plannable dates for sending emails for tickets | Design & Implement | Link |
| 6 | Improved/up-to-date full-text search for tickets (including attachments), FAQ entries and config items | Design & Implement | Link |
| 7 | Refactoring of JavaScript code | Implement | Link |
| 8 | Add Mojolicious | Design & Implement | Link |
Other ideas?
Just create an issue and mark it as "Question".
| name | Mentor Years | Experience |
|---|---|---|
| Johannes Nickel | - | Consultant/Dev |
| Jens Pfeifer | - | Dev |
| Denny Korsukéwitz | - | Dev |
| Roy Kaldung | - | Consultant/Dev |
Support for regular expressions in Generic Agent filters
Description:
The Generic Agent does not support regular expressions in the filter section for attributes, just wildcards like * or %. We would like to see an implementation which allows regular expressions to be used in the text fields of the filter section.
Prerequisite:
- Perl knowledge
Nice to have:
- Znuny or OTRS knowledge
Difficulty:
- easy
Mentors:
- Johannes Nickel @hanneshal
- Jens Pfeifer @jepf
Support for empty values in Generic Agent filters
Description:
The Generic Agent which is used to perform maintenance and supportive tasks does not support a check for empty values in its filters. We would like see a solution where it is possible to explicitly check for empty values in the filter section.
Prerequisite:
- Perl knowledge
Nice to have:
- Znuny or OTRS knowledge
Difficulty:
- medium
Mentors:
- Johannes Nickel @hanneshal
- Jens Pfeifer @jepf
Support for negations in conditions for ticket notifications
Description:
Users of the Znuny service desk have the possibility to create custom notifications. These notifications get triggered by specific conditions. We often get the request that a notification should be triggered if a ticket "does not have" a specific value. This is currently not possible and should be implemented.
Prerequisite:
- Perl knowledge
Nice to have:
- Znuny or OTRS knowledge
Difficulty:
- easy
Mentors:
- Johannes Nickel @hanneshal
- Jens Pfeifer @jepf
Support for inline text modules
Description:
In the Znuny service desk we use CKEditor to create richtext content for emails, notes and replies. We already have an extension which allows to use text modules in a separate widget. We would like to use this as a base for inline text modules. The user should be able to type a special keyword followed by "search keywords" which then get autocompleted to a text module.
Prerequisite:
- Perl knowledge
- JavaScript knowledge
- HTML and CSS knowledge
Nice to have:
- Znuny or OTRS knowledge
Difficulty:
- medium
Mentors:
- Roy Kaldung @rkaldung
- Johannes Nickel @hanneshal
- Jens Pfeifer @jepf
Plannable dates for sending emails for tickets
Description:
In the Znuny service desk we send a lot of emails. Sometimes a user would like to send an email for a ticket later at a specific date and time. A user should be able to select a date and time and mark the email for timed delivery. The timed delivery is already technically possible in Znuny but not controllable by the user.
Prerequisite:
- Perl knowledge
- JavaScript knowledge
- HTML knowledge
Nice to have:
- Znuny or OTRS knowledge
Difficulty:
- medium
Mentors:
- Roy Kaldung @rkaldung
- Johannes Nickel @hanneshal
- Denny Korsukéwitz @dennykorsukewitz
Improved/up-to-date full-text search for tickets (including attachments), FAQ entries, and config items
Description:
The existing full-text search covers only a portion of the existing content by creating a very generic search index on the fly.
A new search should work on all relevant parts of tickets, their attachments, and other objects like FAQ entries.
Prerequisite:
- Perl knowledge
Nice to have:
- Znuny or OTRS knowledge
Difficulty:
- medium
Mentors:
- Roy Kaldung @rkaldung
- Johannes Nickel @hanneshal
- Denny Korsukéwitz @dennykorsukewitz
Refactoring of JavaScript code
Description:
The JavaScript code in Znuny is very old and should be brought up to today's standards. Znuny uses its own JavaScript "framework", so keep in mind that a refactoring might not be possible by integrating a popular JavaScript framework or library. Also, function names and signatures must stay the same because there are many third-party packages which use the existing JavaScript code.
Prerequisite:
- JavaScript knowledge
- HTML knowledge
Nice to have:
- Znuny or OTRS knowledge
Difficulty:
- medium
Mentors:
- Johannes Nickel @hanneshal
- Denny Korsukéwitz @dennykorsukewitz
- Jens Pfeifer @jepf
Add Mojolicious to the znuny stack
Description:
We like to add RESTful methods to the Znuny Core, to enable some cool features in the future.
This is one of the more challenging tasks. We'd like to start with some smaller Znuny-objects in the
admin area to keep it as simple as it can be.
This tasks is about:
- design the interface
- adding Mojolicious
- Implement three objects (System Adresses, Salutation, Signatures,Queues) -- Add tests
- Optional: autamate documentation for the RESTful API
Prerequisite:
- Experience with RESTful services
- Perl knowledge
Nice to have:
- Experience with RESTful services
- Mojolicious experience
- Znuny or OTRS knowledge
Difficulty:
- medium
Mentors:
- Johannes Nickel @hanneshal
- Jens Pfeifer @jepf
