Request with the stats system

[honkinpigs]

Firstly sorry if this was the wrong place to post requests/suggestions however couldn't get hold of anyone in the IRC to check.

Was just a small suggestion with the stats system, would love it to be able to check the stats between two given dates or since a given date, for example;

/reportrts stats notch 01/01/2015
Would check the stats since that date and;

/reportrts stats notch 01/01/2015 07/01/2015
Would check the stats between those dates.

The only other thing i'd like to suggest is being able to run a stats check on all people at once, thanks for your time. Great plugin and keep up the good work!

[ProjectInfinity]

Interesting. Not sure how I feel about it, but I'll keep it up for other people to see and comment upon.

[Stoux]

Currently implementing our own way hacky way to check this. Would love to see this in the plugin by default!

[Telluur]

I would love this feature.

[ProjectInfinity]

@Stoux how are you implementing this yourself? By reading the database from another plugin/application, or have you forked ReportRTS?

[Stoux]

@ProjectInfinity First tried it by listening to the events ReportRTS throws. Found out those weren't really reliable (probably because you assign values (like ID) after the event?) so eventually just imported your whole DB into another DB to store the results (as we reset ReportRTS fairly often). Then read from that database.

[ProjectInfinity]

@Stoux Which event are you listening to? When I look at TicketCompleteEvent then you can see the ticket object, can you not do ticket.getId()?

edit: Ignore that, I meant that the ticket object is passed to any event that extends TicketEvent, simply use that and do ticket.getId().

[Stoux]

@ProjectInfinity I used the events right after you added it so they have changed quite a bit; especially with that big change of 3 days ago. Might have also been why they weren't realiable back then. We generally reset ReportRTS when we hit 1000 requests as it's get a pain in the ass to type. I'm however very keen on keeping stats & stuff so that's the reason why we mirrored the database. It's not uncommon that a ticket is reopened so that brings new problems when you're mirroring the DB through events.

So for me the most ideal situation would be able to reset the TicketID counter while being able to retain the information of old tickets (my stuff does this by having a double primary key; TicketID + Iteration, where the iteration gets incremented & the ticketID reset to 1 when we do a reset).

I used to listen to the ReportCompleteEvent, here's some terrible 1 year old code that we used. All the code in that package is terrible :')...