Re: [Mantisbt-dev] Submitting New Features?

[Julian F. <ju...@be...>]

Wow, you've certainly been busy!!

Are these changes against 0.17.5 or against CVS HEAD?  The code base has 
changed a *lot* since 0.17.5 and there's no way patches would apply 
cleanly from that version.  So the first issue, unfortunately, is that 
if you don't have your patches working against HEAD, you'll probably 
have to do that first (unless someone else wants to take your existing 
patches and move them up).  0.18 is basically in a feature freeze at 
this point too, so we'd be looking at applying these after that is 
released.  But we can certainly set up a branch or something to work on 
them in the meantime.

Lincoln Maskey wrote:
> Hi guys,
> 
> Apologies if this is not the best way to bring this up, but I was wondering
> about the process of getting new features that we've coded into the main
> base? I've suggested them in the Patches forum, but I don't know how often
> it's frequented by you guys.

Ugh... I keep saying we should delete those because I don't have time to 
read forums and mailing lists.  Apparently some of the other developers 
read it but I dunno... I'll vote once more for getting rid of them.  I 
don't have time for pull technology... I need the messages sent to me or 
I'll never see them.

> Anyway, we've added code for the following features and wanted to know if
> any of them would be desirable for the main branch, and if so, how to submit
> the changes.

Well you would submit them by posting patches (ideally for one feature 
at a time if that's possible) to this list.  If you can include detailed 
log messages indicating what changes were made in each file/function and 
the reason for them it helps out a lot (have a look at the cvs logs in 
the archive for examples).

Then someone would pick up the patch, review it, and apply it.  I tend 
to do a lot of that, though I've been so busy the last month I've hardly 
done anything.  In fact that reminds me I better look at my patch queue, 
sorry to anyone whose patches I haven't looked at.

> * Email Severity Preferences: this allows users to set a severity level for
> each type of email notification before being sent an email. For example, I
> get emailed when any level bug is assigned to me, when any new
> major-or-above bugs are entered into the system, and when any minor-or-above
> bugs are reopened. This requires a database change / addition, but it's well
> worth it for user sanity.

This sounds fairly useful, though I'd want to look at the type of 
database changes before committing to the idea.

> * Extra Filters: resolution, build number, version name/number and last date
> changed. Date filters have been hidden in the HTML for some time, but still
> didn't affect the SQL. I've also added a "Use Date Filters" checkbox filter
> (so the user doesn't have to set a range of dates to cover all bugs if
> that's what they want) and a "And None" checkbox filter to apply to assignee
> filtering. This way, you can see all bugs assigned to someone, while still
> seeing those that aren't assigned to anyone. We use this, for example, to
> see what bugs we have to deal with specifically, while not losing track of
> how many new bugs are coming in.

(see comments below)

> * New Filter Display: Because of these extra filters, screen real estate was
> starting to diminish. So now if Mantis is configured to use Javascript, all
> of the filters are just shown as text, with hyperlinks to a popup screen
> with the original filters selection view. Each hyperlink is tied to its own
> option in the popup so that if I click on the "Reporter" link, the popup
> will automatically highlight the reporter drop list. The "Seach" text field
> has been kept on the main page, however, as it seemed as though once the
> other filters where set, we mainly used the text search facility.

Filters are something that definitely need improvement, and yes we do 
need to pull them off onto a different page.  I'd also like to try and 
get away from using cookies for them as much as possible.  Ken has 
already done some work on this, and I have some ideas in the back of my 
mind too.  I would be very interested in seeing how you approached the 
problem and seeing if it fits in with our ideas.  We could definitely 
get a dialogue going on this stuff and start hashing out exactly how it 
should work.  Perhaps it's exactly what you've done; perhaps it needs 
some tweaking.  But I'm definitely interested.

I'd like to see something with various filter classes that know how to 
ask for parameters and then generate the appropriate SQL.  Then users 
could select filter skeletons of various types from a list, fill in the 
variables, and save them in the database (we can just serialize the 
objects).  Then we need something like what you're talking about to 
allow you to apply a filter temporarily, or make it your default, or 
whatever.  This is somewhat longterm, but it's what I'd like to see.

> * New Build List Selection: When currently reporting bugs, the build field
> is a text box. We use a function to generate a list of current build numbers
> in the system so that the reporter can just select it. The list also always
> contains a "Create New" option which, if selected, allows the user to type a
> new build number into a free text box beside it. This helps us to manage
> build numbers in the system (and helps with filtering when everyone uses the
> same build text), while still giving reporters the ability to add new
> numbers as the project progresses.

This also sounds useful, though there's a possibility that the build 
field should go away in favour of being able to add it as a custom 
field.  It's not something that applies in a lot of cases.  So it might 
be that it would be better to extend the custom field stuff to support 
this functionality.  But again, I'd like to see your code and see how 
extensive the required changes are - it might be appropriate for the 
short term.

> * Bug View Hyperlink System: I developed this originally for the main page
> "Bugs Assigned to me" / "Bugs Reported by me" links. It creates a hyperlink
> to a temporary filter view such that cookies are not affected. This way, if
> the users just reclicks the "View Bugs" link, they will have their filters
> set as usual. The way it currently is set up is so that if, when viewing the
> temporary filter view, the user clicks "Apply Filters", they will set them
> permanently. When the new code was introduced into the main Mantis branch
> for those two main page links, I kept my system running, but now have added
> a configuration field for the user to decide whether any bug view hyperlinks
> will set the filter permanently, or just for that view. The way I have
> written this code is to use defaults when a field is not explicitly set.
> This way, when adding new filters, you won't have to change all of the links
> to set that new field, too.

This is related to my comments about filters above.  But again, I think 
this is very useful.


> * Summary Page Hyperlinks: Anywhere possible, numbers in the summary page
> reports now link to filtered bug views (using the above system). The "Open /
> Resolved / Closed / Total" reports, as well as the "by date" report are all
> hyperlinked (using no text decorations so as to not end up with underlined
> links: they were an eyesore!)

Very nice.  Definitely a nice feature to have.

> * A Few Extra Summary Reports: Reporting developer / resolution, reporter /
> resolution, and a "reporter effectiveness" report that we use internally.

Again, I see no problem with adding reports.  We may want to start 
splitting them up so we don't have one slow page, but whatever.  Note 
that the summary page was rewritten recently to reduce the number of 
queries significantly.

> In summary, I guess, we've added email severity preferences, summary
> hyperlinks and extra filters. But I really needed to describe them a bit
> better.
> 
> I understand that not all of these features will be wanted in the main
> branch, but I am sure that a lot of people will find at least some of it
> helpful. And it sure would help me for the next version release :)
> 
> 
> Anyways, this is final question: are any of these features warranted in the
> main branch and if so, how do I go about getting them in?
> 
> Thanks for all your efforts: this system is an absolute godsend in our
> company.

Well, they all sound like good features.  The only question will be 
whether it is the right time and the right way to implement them or 
whether they should be tied in with other changes, etc.

I would suggest, assuming you have patches against HEAD, that you post 
patches for each feature so people can try them out.  But if you want to 
discuss it more real-time, feel free to drop into IRC (though I haven't 
been in there in weeks.. sigh) or send me an email and we can instant 
message or something.

Julian