[Rt-devel] [PATCH]: Show only the Queues that have open tickets in them

Ruslan Zakirov ruz at bestpractical.com
Mon Feb 28 13:43:27 EST 2011


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 ok

On Mon, Feb 28, 2011 at 10:48 PM, Andreas Marschke
<xxtjaxx at 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 at 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: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>> --
>> Best regards, Ruslan.
>
> --
> Cheers,
>
> Andreas Marschke
> _______________________________________________
> List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>



-- 
Best regards, Ruslan.


More information about the rt-devel mailing list