Hi everyone!
This is my first patch so please be gentle and tell me where I went
wrong.
This Patch applies to 3.8.8 and should in theory also appoly for
3.8.10. It was tested on a Debian system with a rt3.8.8 installed.
In larger environments with lots of customers and a queue-per-customer
strategy for managing incoming tickets, RTs QueueSummary is becoming
an issue.
Suppose you have an instance of RT v3.8.8 with about 20-30
queues. Going through these as a single dispatcher just to look for
that one ticket that came this morning is a big work load for really
minimal benefit. Therefore I patched share/html/Elements/QueueSummary
to show only those Queues that have an open or new ticket in them.
I believe more than just a few people here do have had this experience
or had reports of it at their companies.
I would appreciate any feedback you have about it.
Cheers,
Andreas Marschke
QueueSummary-show-only-important.patch (1.12 KB)
Hello,
It can live as a patch for 3.8. It sure wouldn’t be in 3.8 core. It
wouldn’t be in 4.0.0 as it’s a feature and we’re in features freeze.
We already have similar code in “4.2/queue-summary-refactoring” branch
for RT 4.2 (may be 4.0.1) that does what your patch does, but also
hides columns with all zeros and makes it configurable by users in the
Web UI.On Mon, Feb 28, 2011 at 7:13 PM, Andreas Marschke xxtjaxx@googlemail.com wrote:
Hi everyone!
This is my first patch so please be gentle and tell me where I went
wrong.
This Patch applies to 3.8.8 and should in theory also appoly for
3.8.10. It was tested on a Debian system with a rt3.8.8 installed.
In larger environments with lots of customers and a queue-per-customer
strategy for managing incoming tickets, RTs QueueSummary is becoming
an issue.
Suppose you have an instance of RT v3.8.8 with about 20-30
queues. Going through these as a single dispatcher just to look for
that one ticket that came this morning is a big work load for really
minimal benefit. Therefore I patched share/html/Elements/QueueSummary
to show only those Queues that have an open or new ticket in them.
I believe more than just a few people here do have had this experience
or had reports of it at their companies.
I would appreciate any feedback you have about it.
–
Cheers,
Andreas Marschke
List info: The rt-devel Archives
Best regards, Ruslan.
Thanks for the heads up.
I’m looking forward to 4.0. Hope it lands soonish.
I too have a fork of rt at github. There are misc-fixes and things I
noticed could be better. It will probably grow over time.
Is there any actual policy for pull request or peer-review from core
people? Or people who are deeper into RT than myself?On Mon, Feb 28, 2011 at 09:49:26PM +0500, Ruslan Zakirov wrote:
Hello,
It can live as a patch for 3.8. It sure wouldn’t be in 3.8 core. It
wouldn’t be in 4.0.0 as it’s a feature and we’re in features freeze.
We already have similar code in “4.2/queue-summary-refactoring” branch
for RT 4.2 (may be 4.0.1) that does what your patch does, but also
hides columns with all zeros and makes it configurable by users in the
Web UI.
On Mon, Feb 28, 2011 at 7:13 PM, Andreas Marschke xxtjaxx@googlemail.com wrote:
Hi everyone!
This is my first patch so please be gentle and tell me where I went
wrong.
This Patch applies to 3.8.8 and should in theory also appoly for
3.8.10. It was tested on a Debian system with a rt3.8.8 installed.
In larger environments with lots of customers and a queue-per-customer
strategy for managing incoming tickets, RTs QueueSummary is becoming
an issue.
Suppose you have an instance of RT v3.8.8 with about 20-30
queues. Going through these as a single dispatcher just to look for
that one ticket that came this morning is a big work load for really
minimal benefit. Therefore I patched share/html/Elements/QueueSummary
to show only those Queues that have an open or new ticket in them.
I believe more than just a few people here do have had this experience
or had reports of it at their companies.
I would appreciate any feedback you have about it.
–
Cheers,
Andreas Marschke
List info: The rt-devel Archives
–
Best regards, Ruslan.
Cheers,
Andreas Marschke
We don’t have “RT development during git times” policy published at
the moment. Guys just too busy these days.
-
Use branches for every feature, even if it’s one commit. You always
can merge them into your master branch.
-
Tests should pass before branch can be merged.
-
We wouldn’t merge features into 3.8. Unless it’s a security feature/fix.
-
We woudln’t accept bug fixes that are not regressions since RT
3.8.0. So if thing was not working in all 3.8 releases then it
wouldn’t work in next 3.8.x release. Unless it’s a security fix.
-
Tests++ Tests for existing related code paths ++++
-
Github pull requests are okOn Mon, Feb 28, 2011 at 10:48 PM, Andreas Marschke xxtjaxx@googlemail.com wrote:
Thanks for the heads up.
I’m looking forward to 4.0. Hope it lands soonish.
I too have a fork of rt at github. There are misc-fixes and things I
noticed could be better. It will probably grow over time.
Is there any actual policy for pull request or peer-review from core
people? Or people who are deeper into RT than myself?
On Mon, Feb 28, 2011 at 09:49:26PM +0500, Ruslan Zakirov wrote:
Hello,
It can live as a patch for 3.8. It sure wouldn’t be in 3.8 core. It
wouldn’t be in 4.0.0 as it’s a feature and we’re in features freeze.
We already have similar code in “4.2/queue-summary-refactoring” branch
for RT 4.2 (may be 4.0.1) that does what your patch does, but also
hides columns with all zeros and makes it configurable by users in the
Web UI.
On Mon, Feb 28, 2011 at 7:13 PM, Andreas Marschke xxtjaxx@googlemail.com wrote:
Hi everyone!
This is my first patch so please be gentle and tell me where I went
wrong.
This Patch applies to 3.8.8 and should in theory also appoly for
3.8.10. It was tested on a Debian system with a rt3.8.8 installed.
In larger environments with lots of customers and a queue-per-customer
strategy for managing incoming tickets, RTs QueueSummary is becoming
an issue.
Suppose you have an instance of RT v3.8.8 with about 20-30
queues. Going through these as a single dispatcher just to look for
that one ticket that came this morning is a big work load for really
minimal benefit. Therefore I patched share/html/Elements/QueueSummary
to show only those Queues that have an open or new ticket in them.
I believe more than just a few people here do have had this experience
or had reports of it at their companies.
I would appreciate any feedback you have about it.
–
Cheers,
Andreas Marschke
List info: The rt-devel Archives
–
Best regards, Ruslan.
–
Cheers,
Andreas Marschke
List info: The rt-devel Archives
Best regards, Ruslan.