From: <Chr...@he...> - 2003-08-27 07:45:03
|
> From: jl...@ca... [mailto:jl...@ca...] > > On Wed, 27 Aug 2003 11:06:54 +1000, Robert Foster > <rf...@mo...> wrote: > > > Radical thought.... > > How about an XML structure? Which could easily be inserted > into the db... > > Sounds good. At least it's an established standard. > > Still, all the ideas I'm hearing make it impossible to put > PHP code in the > config and dynamically generate it. That's a bit of a shame. IMHO it's a big security benefit if the config "file" can't have working code! > Another thought: perhaps we should convert all language files > into Unicode? > The problem with that is that we have to find a way to > convert old data. There's a nice tool that comes at least with SuSE: recode CU, Christian |
From: Lincoln M. <Lin...@qu...> - 2003-08-29 05:36:32
|
Well for selfish reasons I'd like to suggest a few feature additions for the next release. These are all things that we have currently running in our build without any (visible) issues, and are things that I brought up earlier on this list before deciding to wait until after the 0.18.0 release. So I guess it's time again to bring it up! By the way: apologies now for the long post! Before I get to that, though, the one thing that I haven't seen mentioned yet (I don't think) is related to cookies. I don't care too much between cookies and sessions but if cookies are to be used, I'd love to see the filters stored in a database table or something similar with maybe the cookie just storing an index. My (as I said, selfish) reasons are that: 1) My next big effort will be related to advanced filters (for example being able to select multiple reporters etc.) which may, at one stage, end up getting bigger than the size limit of cookies (OK, so maybe not), but more importantly... 2) I want to start "storing" queries (I've been told that Bugzilla allows this). By having a query/filter database we can easily store and retrieve any number of filters per user. I guess the easiest way for now would be to just store what would have been the cookie string in the database and return the index to the browser in the cookie. That way the only real change that would need to be done is that instead of reading the cookie string, we read the index and grab it from the database, and then parsing and everything else should be the same. I understand that this is a database change, and hence should be left until 0.19, but I wanted to get it out there anyway. It is definitely something that I think we will be pursuing before then. Here is a list of things that we have added, and are happy to submit for the 0.18.x branch if the group decide that they're worth it (note that these have just been copied out of one of my old emails but this way everyone will still know what I'm talking about. Julian made a few comments about these but I obviously haven't included them here). I've tried to put them in order of use... 1) Extra Filters: resolution, build number, version name/number and last date changed (possibly date submitted (we may have changed it). We may also have added some more filters: I don't have it in front of me at the moment). 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 an "And None" checkbox filter to apply to assignee filtering. This way, you can see all bugs assigned to someone (or yourself), while still seeing those that aren't assigned to anyone (for example, any new bugs). 2) 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 "Search" 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. 2.1) As this pop-up page is only used if Javascript is on, we obviously had to update the normal "in-page" filter options. This was present on both the main bug view page and the bug print page so we moved this section of code into a function so that one piece of code could draw up the filters section for both pages. 3) Summary Page Hyperlinks: Anywhere possible, numbers in the summary page reports now link to filtered bug views (using the system mentioned below). 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!) 4) 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 be set 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. 5) 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. 6) A Few Extra Summary Reports: Reporting developer / resolution, reporter / resolution, and a "reporter effectiveness" report that we use internally. Finally, we also added Email Severity Preferences that allow 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. All of these changes have been merged into 0.18.0rc1 code, and so is pretty much up to date. If any of these changes are desired I'm more than happy to do diffs, but naturally I'll need a few days for each one to separate the various pieces of functionality. Thanks, Lincoln. |
From: Glenn H. <ghe...@al...> - 2003-08-29 18:37:47
|
I've been asked for most of these things too. I was going to implement/port some of Lincoln's previous changes on top of 0.18 for my local installation. I'll post the changes as I go. On Friday, August 29, 2003, at 01:35 AM, Lincoln Maskey wrote: > Well for selfish reasons I'd like to suggest a few feature additions > for the > next release. These are all things that we have currently running in > our > build without any (visible) issues, and are things that I brought up > earlier > on this list before deciding to wait until after the 0.18.0 release. > So I > guess it's time again to bring it up! > > By the way: apologies now for the long post! > > > > Before I get to that, though, the one thing that I haven't seen > mentioned > yet (I don't think) is related to cookies. I don't care too much > between > cookies and sessions but if cookies are to be used, I'd love to see the > filters stored in a database table or something similar with maybe the > cookie just storing an index. My (as I said, selfish) reasons are that: > > 1) My next big effort will be related to advanced filters (for example > being > able to select multiple reporters etc.) which may, at one stage, end up > getting bigger than the size limit of cookies (OK, so maybe not), but > more > importantly... > > 2) I want to start "storing" queries (I've been told that Bugzilla > allows > this). By having a query/filter database we can easily store and > retrieve > any number of filters per user. > > I guess the easiest way for now would be to just store what would have > been > the cookie string in the database and return the index to the browser > in the > cookie. That way the only real change that would need to be done is > that > instead of reading the cookie string, we read the index and grab it > from the > database, and then parsing and everything else should be the same. I > understand that this is a database change, and hence should be left > until > 0.19, but I wanted to get it out there anyway. It is definitely > something > that I think we will be pursuing before then. > > > > > Here is a list of things that we have added, and are happy to submit > for the > 0.18.x branch if the group decide that they're worth it (note that > these > have just been copied out of one of my old emails but this way > everyone will > still know what I'm talking about. Julian made a few comments about > these > but I obviously haven't included them here). I've tried to put them in > order > of use... > > 1) Extra Filters: resolution, build number, version name/number and > last > date changed (possibly date submitted (we may have changed it). We may > also > have added some more filters: I don't have it in front of me at the > moment). > 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 an "And None" checkbox filter to apply to assignee > filtering. > This way, you can see all bugs assigned to someone (or yourself), while > still seeing those that aren't assigned to anyone (for example, any new > bugs). > > 2) 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 "Search" 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. > > 2.1) As this pop-up page is only used if Javascript is on, we > obviously had > to update the normal "in-page" filter options. This was present on > both the > main bug view page and the bug print page so we moved this section of > code > into a function so that one piece of code could draw up the filters > section > for both pages. > > 3) Summary Page Hyperlinks: Anywhere possible, numbers in the summary > page > reports now link to filtered bug views (using the system mentioned > below). > 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!) > > 4) 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 be set > 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. > > 5) 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. > > 6) A Few Extra Summary Reports: Reporting developer / resolution, > reporter / > resolution, and a "reporter effectiveness" report that we use > internally. > > > > Finally, we also added Email Severity Preferences that allow 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. > > All of these changes have been merged into 0.18.0rc1 code, and so is > pretty > much up to date. If any of these changes are desired I'm more than > happy to > do diffs, but naturally I'll need a few days for each one to separate > the > various pieces of functionality. > > Thanks, > Lincoln. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > -- Glenn Henshaw Altera Ottawa Technology Center Phone: (613) 591-6702 Email: ghe...@al... -- Glenn Henshaw Director Altera Ottawa Technology Center Phone: (613) 591-6702 Email: ghe...@al... |
From: Kenzaburo I. <ke...@30...> - 2003-08-29 20:44:25
|
Great stuff (you other guys too)! I've implemented some of these already for one-off custimizatoins so some of these are definitely going to get into the short-term roadmap. I'm not too keen on javascript since it can become a crutch but we're definitely going to be using more of it. Just as a reminder/fyi, I'm storing these feature and suggestions in our Wiki where we'll sort them out as we move forward. Thanks, -Ken > Well for selfish reasons I'd like to suggest a few feature additions for > the > next release. These are all things that we have currently running in our > build without any (visible) issues, and are things that I brought up > earlier > on this list before deciding to wait until after the 0.18.0 release. So I > guess it's time again to bring it up! > > By the way: apologies now for the long post! > ... snip ... > Thanks, > Lincoln. |
From: Jeroen L. <jl...@ca...> - 2003-08-27 07:50:58
|
On Wed, 27 Aug 2003 09:44:13 +0200, <Chr...@he...> wrote: >> From: jl...@ca... [mailto:jl...@ca...] >> >> On Wed, 27 Aug 2003 11:06:54 +1000, Robert Foster >> <rf...@mo...> wrote: >> >> > Radical thought.... >> > How about an XML structure? Which could easily be inserted into the >> db... >> >> Sounds good. At least it's an established standard. >> >> Still, all the ideas I'm hearing make it impossible to put PHP code in >> the config and dynamically generate it. That's a bit of a shame. > > IMHO it's a big security benefit if the config "file" can't have working > code! Perhaps... but some larger sites might want to use it for example for virtual hosts, and we use it to provide sensible defaults (which of course we could still do as a one-time generation). >> Another thought: perhaps we should convert all language files into >> Unicode? The problem with that is that we have to find a way to convert >> old data. > > There's a nice tool that comes at least with SuSE: > > recode Can we also update the database content with that? Ideally we should that conversion as a database upgrade script. Jeroen |
From: Kenzaburo I. <ke...@30...> - 2003-08-27 16:39:14
|
>>> Still, all the ideas I'm hearing make it impossible to put PHP code in >>> the config and dynamically generate it. That's a bit of a shame. >> >> IMHO it's a big security benefit if the config "file" can't have working >> code! > > Perhaps... but some larger sites might want to use it for example for > virtual hosts, and we use it to provide sensible defaults (which of course > we could still do as a one-time generation). There's no reason we couldn't also have some code that runs when the config file is loaded. After all, at least the database information ahs to stay in a file somewhere. Not to mention allowing for 'pre-processing' should something like plugins be introduced. -Ken |