v1.0.0 roadmap

[thekordy]

I think it's the time for a full upgrade including the core and the features as well.

My plan is to address these issues in the v1.0.0 release (Not necessary in same order, and not necessary in the first release, but can be added in patches):

1. Full rewrite of the dashboard queries to low down the number of queries and make it faster. #71 (done in efd7461d85718c25beae5cfb68f184bf186e19d1)
2. Full rewrite of the settings database and Settings management panel
3. Tickets filters by department, user, agent, category, ..etc
4. Sub-tickets #16
5. boilerplate compatibility #26 (I don't know, but i will give it a try)
6. Ability to Disable Priorities and Categories #27
7. Admin master template separate of the front master #28
8. Add Ids and classes to Ticketit templates divs and elements #29
9. Relationship restrictions #53
10. Create tickets through webform #69
11. Create tickets through email #69
12. Attachments to tickets #70 (done at #108)
13. Private comments #94 (done in c2e462f8b4170467a161a8bd1699c9d050e37ee0)
14. Agent teams/groups (while the auto assign solves a part of it, may be we need to add permission for agent to work on his department issues) #94
15. Ability for agent to assign owner of ticket for customers that call in by phone #94
16. Service Level Agreements (SLAs) where specific actions/escalations are taken based on ticket timelines #94
17. ticket timeline (audit)
18. more agent restriction permissions (ex. agent can view category tickets but can't edit, can view and edit, can view all categories tickets but can't edit, ..etc)
19. Make a config file for fallback, so if any thing goes wrong and can't access web interface, user can change configuration in the config/ticketit.php file then issues php artisan db:seed --class="Kordy\Ticketit\Seeds\SettingFallbackSeeder" to reset the ticketit settings in the database #78 #91 (done at e87270c9314da14c4c14317b672a3996e77fa8af )
20. Handle errors and exceptions and provide errors logging

[tmcdon89]

On number 11 what were your initial thoughts on that? Should it be some sort of controller page that allows services like mailgun to pipe json to it, or were you thinking more along the lines of the application pulling emails from an imap account more along the lines of this: https://github.com/barbushin/php-imap

[thekordy]

or were you thinking more along the lines of the application pulling emails from an imap account more along the lines of this: https://github.com/barbushin/php-imap

That's it, and I think we can use a package like that one. To be more clear, we would have a new controller that depends on a third party email piping (like barbushin/php-imap) .. this controller would check the support email inbox every period of time for new emails, if found any new email, it will create a new ticket with the subject of the email as ticket subject, and the email body as the ticket body, and the sender as ticket owner.

Some points to think about:

1. How it would work with a sender who is not registered?
2. Attachments
3. We will need to filter email body to remove signature and history quotes (if user is replying to ticket notification).

[jetwes]

This is awesome, especially the ticket creation via email - thats a thing i thought of first. If i can help in anyway - you're welcome

[tmcdon89]

My thoughts on the points provided:

1. I think there should be a checkbox option to either auto create accounts for unrecognized emails or not accept them. It could additionally be limited to only auto create accounts based on the domain address of the sender. So if [email protected] sends an email they get an account created. If [email protected] sends one it is ignored/dropped, or potentially dropped into a category for unregistered accounts.
2. I think attachments should be added as an easy click link to download/view. Should definitely have some blocks/ignores on certain file types like .exe and .zip etc...
3. I imagine this one could be tricky to remove their signature. I think mailgun open sourced their code for doing that though so that might be a place to look first.

[thekordy]

@jetwes Thank you for your feeling. You can help by coding, translating, testing, or feedback, any of these would be very appreciated :)

[thekordy]

@tmcdon89 Thanks for the work time PR.

I agree with you on the first and the second points, and I don't think we should waste time on trying to remove the signature, but it's better (and it might be easier) to focus on removing quoted notification.

4. it should search first on the incoming email subject, if present, then it's only a new comment, if not present then create a new ticket.
5. a default category for the tickets created by email
6. I think it's better to start on attachments in tickets first then to go to the email. As we will need it ready when we will work on the email

[tmcdon89]

I am weighing the pros and cons of where to store the attachments. I definitely think its more straight forward to store them on the file system and simply reference their path from the database but it would also be nice having everything contained within the database to easily move between hosts. What are others thoughts on where to store the attachments?

[fishmad]

+1 - store them on the file system and simply reference their path from the database.

On Mon, Dec 14, 2015 at 9:39 AM, tmcdon89 [email protected] wrote:

I am weighing the pros and cons of where to store the attachments. I definitely think its more straight forward to store them on the file system and simply reference their path from the database but it would also be nice having everything contained within the database to easily move between hosts. What are others thoughts on where to store the attachments?

— Reply to this email directly or view it on GitHub https://github.com/thekordy/ticketit/issues/95#issuecomment-164306998.

[jetwes]

yes - i think it's the better option to just reference the path

[thekordy]

on the file system and simply reference their path from the database

:+1:

[thekordy]

to easily move between hosts

You can use relative path in the database, and the attachment class would transform it to the current path

[tmcdon89]

I'm making the assumption that we would want these files stored within the base folder of the Laravel installation? Something like: base_path() . '/Attachments/foo' Where foo is where the attachment came from, such as "Comments" or "Email"

[jetwes]

I would prefer storage_path().'/app/user/ticketit/attachments' - since the storage is for that type of files.

[thekordy]

added new capability to the installer (starting from v0.2.3 +), so the system will check at the start up for any new migrations or settings, if any found, will force the upgrade window for only administrators 8a26f3d7a794022762e33d31afb4983e962a8373

[andylord56]

Looking forward to number 11 however i am thinking there is normally a reply within that ticket with a hash number in it and replying to this adds it to the ticket

[mikerockett]

Hi! Ticketit looks really simple, and easy to use - this is exactly the kind of thing I'm after for a client. However, ticketing-by-email is a must for me, and so I'm a bit lost at this stage (no decent systems out there based on Laravel, which is also a requirement).

Any feedback yet on this roadmap?