2.0 directions

[tmcdon89]

I'm currently working on this but I could definitely use some help. The installation process is rather involved currently and only somewhat documented. I've been trying to work through the various issues as they come up during the installation process. What I'm finding are a lot of oddities that are likely caused by the additional features added/changed in v1. Its been easy enough updating an existing instance of Ticketit but starting from scratch is a painful experience.

So I'm requesting assistance from others to test installing v1 and see what kind of issues you run into. If we gather a set of issues we should be able to iterate through and correct most of them quickly and allow more people access to the great tool we now have.

Thoughts?

[thekordy]

Actually, I have an idea that is getting bigger and bigger everyday, I am thinking of making a totally new version, reviewing all the code again, and get back to the Laravel style. Stability, extensibility, and to be very customizable for developers, should be the main focus of the new version.

Initial points:

1. Get the settings back to the config files
2. Get rid of the installation screen, user may use artisan migrate command instead 3.Tests for everything from now on
3. Routes and models can be overwritten by user custom routes and models (no fixed model path any more), files paths are configurable, and using traits for models functions
4. All features other than the core can be enabled/disabled

These are the initial points I am thinking about for the new version, so we can enable developers to use the maximum potential of Ticketit.

I may add a new branch with initial code for that in few days to explain the idea more. What do you think my friends?

[fishmad]

I like the idea, it became bloated too quickly, happy to some end user testing. On 28 Apr 2016 6:18 pm, "Ahmed Kordy" [email protected] wrote:

Actually, I have an idea that is getting bigger and bigger everyday, I am thinking of making a totally new version, reviewing all the code again, and get back to the Laravel style. Stability, extensibility, and to be very customizable for developers, should be the main focus of the new version.

Initial points:

1. Get the settings back to the config files
2. Get ride of the installation screen, user may use artisan migrate command instead 3.Tests for everything from now on
3. Routes and models can be overwritten by user custom routes and models (no fixed model path any more), files paths are configurable
4. All features other than the core can be enabled/disabled

These are the initial points I am thinking about for the new version, so we can enable developers to use the maximum potential of Ticketit.

I may add a new branch with initial code for that in few days to explain the idea more. What do you think my friends?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/thekordy/ticketit/issues/184#issuecomment-215347133

[balping]

I abolutely agree with you. Starting again from scratch is often much easier than making a huge refactor (which is very much needed).

I think we should drop backward compatibility. And then we could create a migrate script before release, but not necessarily.

Only the 'make tests for everything' part looks scary to me. I agree setting up unit tests improves code quality, but I'm not sure if it's really needed to write tests for everythig.

One extra idea: I think to whole acl part should be done using laravel's gate functionalty.

[tmcdon89]

I think that would be a good direction to head in. Would we be calling this v1 still or move on to v2 for the new code base? Additionally I think that we should lay out what features we want to be in this new version and work towards them. Once they are all in, new features should only go in development branches.

The best way to expand the user base and improve the product is getting it to a good stable state and keeping it there for people while new features are designed elsewhere.

[balping]

Maybe we should use git-flow? For handling stable/dev/bugfix branches

[thekordy]

@balping I know how it looks, but when you see how tests improve the code and decrease the issues a lot, even they helped me to write code faster than before.

@tmcdon89 I was thinking to make it v2. And I'd suggest to keep features at the minimum, and to think of a way to make all features other than the most basic core features (basic Tickets CRUD), and other features work as pluggable extensions, something like hooking into the service provider, or switching controllers in the routes file, So developer who want to add or edit feature, he just need to add new class, without the need to modify existing code. and we can use contracts to make sure our API is preserved.

I still have not got enough thinking about the best way to offer extensions. Does anyone have a good idea on how we could do that?

[balping]

It's not an answer to your question but the very core (crud and related stuff) could be a facade. Then api functions could be called from the entire system (including the 'extensions' we provide). I'm thinking of someting like Ticketit::open() , Ticketit::addAgent(), etc

So a developer could use the api without touching anything in the codebase of this package. This could be useful for example for automatic issue opening (ex error reports)

[thekordy]

2.0 .. What do you think?

@balping I am looking into the Facade option, Thank you for your suggestion

[balping]

Very well done, lot of work you have already done as I can see. :+1: Maybe the hardest thing is to start somewhere...

And it looks really good quality code with comments, tests, etc.

I have a suggestion regarding traits.

If I understand it correctly, a developer should add TicketitUserTrait, TicketitAdminTrait, TicketitAgentTrait to his/her User model in a typical setup. But meanwhile, the classnames of the models for admin/agent/ticketituser have to be specified in the config file as well. So if I'm not mistaken, there's a redundancy.

I think this redundancy could be avoided using a construct / boot method in admin/agent/ticketituser traits. This method should somehow register in Ticketit's core that the class, where the trait was included, should be handled as admin/agent/user model. I think it's possibble by referencing parent::class or someting like this. It's not that tricky. I hope it's clear what I'm trying to say. This way a developer should only care of including traits in the main User class (or wherever they are needed) and shouldn't take care of keeping model files and the config file consistent.

[balping]

One last thing:

"laravel/framework": "^5.2"

Since 5.1 is an LTS release, we should support it as well. So we can't rely on new functions in 5.2

But you may disagree anyway. Maybe when we'll done with this, there will be another LTS release :-P

... or we can say that 0.* branch is for laravel 5.1 and 2.* branch is for 5.2

[thekordy]

there's a redundancy.

Yes, It's right now. But it is just I don't know all the possibilities other developers would need to scale in future, so I opened it for them. Another side of it, as Here I am binding them in the service register, (so I need to know about them at the very early of application startup), and I use these bindings in tests, migrations, and models relations, I don't know other ways to do that. (and they can be converted to Facades anytime very easy, just only one step to be done)

[thekordy]

Since 5.1 is an LTS release, we should support it as well. So we can't rely on new functions in 5.2

That would better of course

[balping]

I see. Ok then

[tmcdon89]

@thekordy when you have a minute it would be greatly appreciated if you could give a rundown on the new way this is working. With emphasis on how to add new features. The reason I ask is to make sure I'm following everything correctly. I program on the side so with my current skill level I want to make sure that I'm not misinterpreting the way its supposed to work.

Thanks!

[thekordy]

I am sorry .. I knew I had to write about that, I just wanted to get there together, So all ideas are very welcome. I will list here the main points in my mind, so we can build a good strategy on it.

Models Extensibility

I just separated the models API from models into Traits, and made models paths are configurable .. So basically it gives developers the option to replace or change APIs or database tables the way they want.

As example, Basically you can use the ticket Facade to create the ticket like this TicketitTicket::create([ default ticket fields here ]) .. So let's say you need to add more fields to the ticket (or even to change its relations or to add new relations or change the table altogether), it's easy:

1. make a migration to alter ticket table to add new columns
2. copy TicketTicket model to the App folder and change namespace and $fillable
3. overwrite any of the TicketTicketTrait default functions and ticket relations (if needed)
4. change the tickets model path in the models config file (found in config/ticketit/models.php after publish)

After that, developer can still use same API TicketitTicket::create([ the new custom fields ]) with the new custom fields.

That's it .. without the need to modify any of the core code :)

Now let's say you need to modify something in the logic or to replace a controller function, that's easy too:

1. create new controller at app controllers folder
2. extend the Ticketit controller you need modify
3. modify the config/ticketit/routes.php to change the action path Ex.

    'tickets-index' => [
        'path' => '/tickets',
        'action' => 'Kordy\Ticketit\Controllers\TicketsController@index',
        'middleware' => ($laravel_version == "5.2") ? ['web', 'auth'] : 'auth'
    ]

to

    'tickets-index' => [
        'path' => '/tickets',
        'action' => 'App\Http\Controllers\TicketsController@index',
        'middleware' => ($laravel_version == "5.2") ? ['web', 'auth'] : 'auth'
    ]

Also as you noticed, the middleware can be changed.

So as you can see, the plan here is to give developers the ultimate control to change and modify any piece without any need to modify the core code.

Configurable Models Relations

I changed the tickets and comments relation to users table from belongsTo into morphTo .. That would allow a relation with multiple tables, so if you have admins table and users table and you want both be able to create tickets, no problem just add the TicketitUserTrait to each model you want to create tickets and comments.

Also the database relation with users, agents, and admins are configurable, the migration will get what table to relate with from the models config file .. people can use any of users management systems and they still can use ticketit

Functions Extensibility

Well, I have not worked yet on a solid concept about how to add features, but I think we were doing a good work before as we made config option to enable or disable every feature, Also I'd like to think about features as plugins, no changes should be made on the core only to plug a link to the feature separated class.

class TicketsController extends Controller
{

    public function index()
    {
        $this->ticketsCollections = TicketitTicket::get();

        if ( config ( 'ticketit.extensions.featureX' ) ) {
            FeatureXController::featureX($this)
        }
        if ( config ( 'ticketit.extensions.featureY' ) ) {
            FeatureYController::featureY($this)
        }

Also the same in views

@if( config ( 'ticketit.extensions.featureX' ) )
    @include('Ticketit::extensions.featureX')
@else
   @include('Ticketit::tickets.index.table')

Troubleshooting

Every function or view that expects some parameters, at least must throw an error if any of those parameters is not present or wrong. I also think about some sort of troubleshoot mode, if enabled, a log should state every step has been made by the package, and parameters passed .. that would help a lot in troubleshooting and would be easy to implement it if we adopted it from the beginning.

tests

Of course writing tests for all main functions at least will help maintaining a stable code.

wiki

We can maintain a very good documentation if we required any new commit that changes or add new behaviour to document it or to change its corresponding wiki.

Well, that is what in my mind right now, I also add the CONTRIBUTING as a base policy we can build upon it to keep the package healthy and stable.

[balping]

Great summing-up, thanks for writing this!

As the concepts are getting more solid, it will deserve a wiki page as well.

A little bit back to brainstorming.

In the previous versions I found that translations become a bit messy. English and other languages weren't in sync, it wasn't easy to determine which constants need be translated and which were already done.

So I made a google search and found this package: https://github.com/potsky/laravel-localization-helpers

It could help us to keep translation files clean. Composer allows to install some packages only in dev mode, we could add this one to that part. You don't need such package on production, obviously. It could just help developers who want to translate ticketit to their language.

PS: @thekordy could you create a v2 tag? Now, everything goes to this thread, but sooner or later we'll need to open other issues to discuss more specific problems related to this new version.

[thekordy]

The translation management package is a very good idea :+1:

[thekordy]

As the concepts are getting more solid, it will deserve a wiki page as well.

I think we can get three documents from here:

1. the contribution policy (which we have done much of it here)
2. the developer guide to extend the package
3. v2.0 roadmap that includes what features to be included in the first couple releases.

What do you think about the features we should include in the coming releases?

[balping]

Why not mostly everything we had before? We are not in a hurry, we could do them carefully. So for the first thought:

• index page with search / filter functionality
• agent management
• Auto assignment
• wysiwyg editor [optional]
• attachments (that could belong to comments as well) [optional]
• attachment handling with Laravel's flysystem https://github.com/thekordy/ticketit/issues/238
• email notifications (but not imap parse yet) [optional]
• close / reopen statuses
• nice admin dash with charts [optional]
• public issue opening (no registrated user requied) with captcha and tracking code [optional] [new]

[optional] means it could be turned on/off in config files, the rest should belong to core functionality. The list might not be complete, feel free to edit my comment to improve it.

[thekordy]

I think we should include a default master view with needed scripts and the developer can change to his own master view later, the only problem is how to make it plays nice with developer current auth routes and how to play nice Laravel 5.1 as well as 5.2

[balping]

Since 50% of issues opened here was because of failing to set up blade correctly, it's a good idea

[thekordy]

This was my last direct commit, next I will only use pull requests to add new commits to v2.0

[balping]

So we should use pull requests as well, I guess. (?)

[shane3xsds]

How is v2 coming along? I am interested in using this for a current project that uses multi auth. It is stable enough to start using? Worth waiting for? Just seeing what options I have at this point.

[thekordy]

v2 is not stable at all, it is not expected to be ready for a month or two at least to go through the full development cycle.

[thekordy]

Updates:

1. I found that the best way to support multiple versions of Laravel (specially the 5.3 is on the way, is to split into multiple versions each is deticated to a single laravel version. Working now on v2.1 for laravel v5.1, will start on v2.2 for laravel 5.2 as soon as I finish the 2.1
2. The authorization part is now done depending on a totally separate auzo-tools package to handle the authorization with help of configurable ACL rules .. very easy for users to adjust the ACL as they wish or disable it and use their own authorization management methods.

Todo:

1. Finish all routes APIs
2. Then the UI

[thekordy]

APIs are almost done, next is the theme

each theme will has its controller and views folder (paths are set in the configuration)

we might provide two basic themes, the standard basic theme (which I will work on at next) .. and a vue theme.

[thekordy]

I will make the administration tasks (agents management, categories, status, ..) are done through artisan commands at first .. may be after the alpha release or something we could find time to release a backend UI

[balping]

Interesting article about inbound mail processing. But we might not want to bind ticketit to mailgun.

https://laravel-news.com/laravel-inbound-email

[mikelearning]

HI @thekordy and @balping I am a student, and I found this tickeit interesting. I am working on a like project but instead of tracking tickets my project tracks document. I want to use this system as my blueprint. but its hard for me by looking and analyzing the src code, I''m just new in programming. I try to look where's the master.blade.php to add some features like: My Profile, for admin/agent/users. were they can edit their own profile something like that. I hope to get some response this