| ../irclogs/#mantishelp.2010-06-10.log | ||
| --- scribe started --- | 00:00 | |
| CIA-22 | Mantisbt: daryn * rb4038b50a16c / (5 files in 3 dirs): Load common.js after jquery conflicts have been resolved. | 05:10 |
|---|---|---|
| CIA-22 | Mantisbt: daryn * r2dc8409eb9d5 / (3 files in 3 dirs): Remove ToggleDiv call from the html and add jquery listener. Modify to use | 05:10 |
| CIA-22 | Mantisbt: daryn * r1819bbdf8c2d / (54 files in 6 dirs): Add html_css_link function and convert hardcoded links to use the function. | 06:02 |
| gunee | Hi everyone. Is there a way to configure Mantis so that the e-mails related to a same bug are threaded ? | 12:35 |
| Cupertino | hi davidinc | 12:45 |
| Cupertino | I see you updated reminder again | 12:45 |
| davidinc | Cupertino: hi | 12:58 |
| Cupertino | :) | 12:59 |
| davidinc | Cupertino: what can I help you/ | 12:59 |
| davidinc | ? | 12:59 |
| Cupertino | nothing m8 | 12:59 |
| Cupertino | just wanted to say hi and say i uploaded your new version | 13:00 |
| nuclear_eclipse | gunee: they should all be part of a single thread afaik, or it at least works that way in Thunderbird | 13:01 |
| davidinc | Cupertino: Cool have fun!! | 13:02 |
| gunee | nuclear_eclipse: thanks for the answer. I use thunderbird though, and messages do not appear as threads. | 13:03 |
| gunee | Is it possible that the Mantis version installed on our server is buggy ? It's 1.0.0 rc 2 | 13:03 |
| nuclear_eclipse | oh | 13:04 |
| nuclear_eclipse | that's quite out of date... | 13:04 |
| nuclear_eclipse | you should *really* try to upgrade to the latest stable versions | 13:04 |
| gunee | so it seems... I'll talk to the server admin about that. What would be the recommended version ? | 13:05 |
| nuclear_eclipse | 1.2.1 is the latest stable version | 13:06 |
| gunee | ok. I'll see what I can do... | 13:06 |
| gunee | Hi again. I've read the documentation about e-mail notifications but I haven't really understood how to replace the $g_to_email parameter. Can someone help me ? | 15:57 |
| nuclear_eclipse | daryn: | 16:18 |
| daryn | lo | 16:18 |
| nuclear_eclipse | gunee: add a new line in your config_inc.php with $g_to_email = "wahatever"; | 16:18 |
| nuclear_eclipse | daryn: re your jquery changes in master | 16:19 |
| daryn | ya? | 16:19 |
| nuclear_eclipse | does that maintain the existing behavior of remembering what divs a user has collapsed for future page loads? | 16:19 |
| daryn | yes | 16:19 |
| nuclear_eclipse | ok, cool, it just wasn't immediately obvious from the diffs :P | 16:20 |
| daryn | it still calls ToggleDiv, it just gets assigned from the script | 16:20 |
| daryn | there is one minor bug i found when hitting the report page the Ajax object is not found and then it forgets the settings. i'll be tracking that down soon | 16:22 |
| daryn | i'm cleaning up filter changes now and piecing together the commits so hopefully you'll have something to look at real soon | 16:23 |
| nuclear_eclipse | awesome | 16:24 |
| daryn | i updated your product matrix plugin as an example as well | 16:24 |
| nuclear_eclipse | wheee! | 16:24 |
| daryn | it isn't 100% because i wasn't sure on a couple of things but at least it will give you an idea of what i'm doing | 16:25 |
| nuclear_eclipse | pvm filters are quite a workaround hack, very tightly tied to the way that mantis internals work... =\ | 16:28 |
| nuclear_eclipse | eg, using a filter to specify a set of columns to force into the current configuration | 16:29 |
| daryn | ok, well, maybe that won't be necessary now. we can talk about it once i push to forge and figure out how it should work | 16:29 |
| nuclear_eclipse | ok | 16:29 |
| nuclear_eclipse | tbh, I did it that way because I didn't like any way of integrating that as part of the core filter/plugin system | 16:30 |
| nuclear_eclipse | ie, better to have the tacky stuff in a single plugin than part of the core APIs | 16:30 |
| daryn | right | 16:30 |
| gunee | nuclear_eclipse: thanks, but is this also valid for version 1.2.1 ? I've done what you suggested, but it doesn't seem to be working. What about the last bullet of this section http://docs.mantisbt.org/master/en/administration_guide.html#ADMIN.CUSTOMIZE.EMAIL ? | 18:44 |
| nuclear_eclipse | gunee: I don't see "to_email" anywhere in config_defaults_inc.php in 1.2.1, so I guess not | 18:49 |
| gunee | This is what I understood when reading the doc I pointed above | 18:51 |
| nuclear_eclipse | unfortunately, much of the admin guide is leftover from 1.0.x and 1.1.x... =\ | 18:52 |
| ultra_blue | Hello, everybody. Mantis 1.1.8. Is there a way to prevent released versions from appearing in the Report Issues page? Thanks! | 18:52 |
| ultra_blue | In the 'Target Version' drop down. | 18:53 |
| gunee | I created an account for our bug reports mailing list, but the mailing list still doesn't receive messages. I'm not sure if I configured the mailing properties for this user correctly... | 18:53 |
| nuclear_eclipse | ultra_blue: a) that should only happen by default for developers or higher, and b) it's a configurable threshold that you could set to NOBODY | 18:53 |
| nuclear_eclipse | ultra_blue: counter intuitively, I believe $g_report_issues_for_unreleased_versions_threshold controls that | 18:55 |
| ultra_blue | nuclear_eclipse: Understood. But I often get confused about which version I'm applying an Issue to, and since we never add Issues to released versions, it would be great if they didn't appear at all. | 18:55 |
| ultra_blue | nuclear_eclipse: sweet. I | 18:55 |
| ultra_blue | 'll take a look. | 18:56 |
| ultra_blue | It looks like $g_report_issues_for_unreleased_versions_threshold controls who can assign Issues to an unreleased version. I want to hide released versions in the 'Target Version' drop down. | 19:02 |
| nuclear_eclipse | hide individual released versions, or all of them? | 19:09 |
| ultra_blue | just individual released versions. | 19:10 |
| ultra_blue | Once we release, there's no need for them appear in that list anymore. Once a release has happened, we can't add any more Issues to it. Cause it's released. | 19:11 |
| ultra_blue | ;) | 19:11 |
| nuclear_eclipse | in that case, you should be able to set the version as "obsolete", which will hide it from the various version dropdowns, as well as the roadmap/changelog, but I don't know of a way to hide individual versions from *only* the target version field, although IMO that sounds like a bug, because you shouldn't be able to set something to target a released version... | 19:12 |
| nuclear_eclipse | per chance, are you using versions inherited from a parent project? | 19:12 |
| nuclear_eclipse | nvm, inherited versions were added in 1.2 | 19:13 |
| ultra_blue | Lemme see if obsolete is an option. | 19:14 |
| nuclear_eclipse | either way, you might want to consider upgrading to version 1.2.1, first to see if it fixes the behavior, but also because it hasa lot of feature and security updates | 19:16 |
| ultra_blue | Good advice. I'll see if I can rattle the system folk chains a little. I don't see any way of setting the version to obsolete in our version. | 19:17 |
| ultra_blue | Thanks for your help! | 19:17 |
| nuclear_eclipse | ultra_blue: that might be yet another feature added in 1.2.x =\ | 19:19 |
| nuclear_eclipse | it's hard to keep track | 19:19 |
| ultra_blue | <nods> But still, you're right, we should upgrade. | 19:19 |
| ultra_blue | How painful is it? | 19:19 |
| ultra_blue | On a scale of 1-10. ;) | 19:20 |
| nuclear_eclipse | about 3 or 4, assuming you don't have any customizations to the code | 19:22 |
| ultra_blue | hardly any. | 19:22 |
| nuclear_eclipse | backup your database/install, copy configs and custom_* to the fresh 1.2.1 install, point your browser at admin/install.php to upgrade the database schema, and that should be it | 19:23 |
| ultra_blue | It took us awhile to realize that we can configure Mantis a lot, and that what comes out of the box isn't necessarily best practice but more of a guideline. | 19:23 |
| nuclear_eclipse | http://git.mantisbt.org/?p=mantisbt.git;a=blob;f=doc/INSTALL;h=e77fc6a7818d89e7ebbd748b345f3ba4b83b3c7c;hb=a6a8ed17748a91e019239beff77869c94198a232 | 19:23 |
| ultra_blue | Ha, sweet. | 19:24 |
| ultra_blue | Systems folk love short instructions. | 19:24 |
| nuclear_eclipse | I don't like writing long instructions :P | 19:25 |
| ultra_blue | Ah, that's your work? | 19:27 |
| nuclear_eclipse | yep | 19:28 |
| gunee | nuclear_eclipse: Still no idea of how to fix this problem ? | 19:29 |
| nuclear_eclipse | gunee: no, I'm not sure | 19:29 |
| nuclear_eclipse | I rarely deal withemail in mantis | 19:29 |
| ultra_blue | Ah. Well thanks again for your attention. | 19:29 |
| gunee | ok. Thanks anyway | 19:29 |
| nuclear_eclipse | ultra_blue: np, hope the upgrade works out | 19:30 |
| shruggar | when trying to view rss feeds for mantis, I get: "APPLICATION WARNING #403: Database field "email" not found." at the top of the xml output. I have already tried running the upgrade script under admin/, and have updated to 1.2.1 | 19:45 |
| shruggar | can someone with a working install send me a mysql schema? | 19:55 |
| gunee | nuclear_eclipse: I finally managed: I created an account with the bug reports ML address, set it up as a viewer account, and then I ticked all the boxes for "viewer" in the E-mail notifications page. | 20:09 |
| gunee | It is cheesy, but it seems to be working. I wonder why the developers have decided to remove this g_to_email setting though... | 20:10 |
| gunee | And e-mails are still not threaded, but I think that comes from our mailing list system. | 20:11 |
| shruggar | apparently, somehow there were some issues with an invalid reporter_id | 20:19 |
| slestak | hi guys. upgradign my 1.1.6 vm to 1.2.1 I have my backups and have copied the new code to the vm. I am getting a 403 forbidden on install.php | 20:54 |
| slestak | i dont think i would need to modify my apache vhost for the upgrade. I see the permission denied in apaches error.log | 20:55 |
| slestak | i tried this from localhost in lynx as well as from remote browser. | 21:06 |
| pconrad | Hi Everyone | 23:31 |
| pconrad | I'm trying to do some custom reporting against the SQL tables for my Mantis install | 23:31 |
| pconrad | and am wondering if anyone knows off the top of their head where the mapping between the bug status codes in the status field of mantis_bug_table and the text status codes lives? | 23:33 |
| pconrad | I'm gonna start hunting through source code in a minute, but I figured I'd ask the room first in case someone just knows off the top of their head | 23:33 |
| pconrad | One of the things I'm trying to do in my custom reports is locate bugs that are either 'resolved' or 'closed' | 23:35 |
| pconrad | I can hard code "90" and "80" in my SQL queries but I'm wondering if there is any reason not to do that... i.e. do these numbers live in a configuration file or a database table somewhere? | 23:38 |
| pconrad | I see code such as config_get( 'bug_resolved_status_threshold' ) that makes me thing that there is some mapping somewhere I might be able to look up... | 23:38 |
| pconrad | Ok, core/config_api.php seems to be the code where the thresholds are looked up | 23:43 |
| pconrad | and it seems you look first in cache, then database, then $GLOBALS | 23:44 |
| pconrad | where are the $GLOBALS set? that's what I haven't found yet | 23:44 |
| pconrad | The answer appears to be core/constant_inc.php | 23:49 |
| pconrad | That's not where $GLOBALS is defined---haven't found that yet---but it is where the relationship between "80" and "90" and "resolved" and "closed" is made | 23:51 |
| pconrad | Sounds like its ok to just hardcode 80 and 90 at least for now----can anyone at least say "yup, sounds ok"? | 23:52 |
Generated by irclog2html.py