| ../irclogs/#mantishelp.2010-08-20.log | ||
| --- scribe started --- | 00:00 | |
| DAloG | Hello everyone) | 01:15 |
|---|---|---|
| DAloG | I hame a small question about Mantis SOAP API. I cant find a way to get issue history over soap. Cann you tell me, some way exist or not? | 01:18 |
| DAloG | if you have some idea, or know that its impossible, please send me a mail to: demedeckie@gmail.com | 01:20 |
| DAloG | thanx for your attention | 01:24 |
| Github | mantisbt: master Robert Munteanu * 3e44f13 (1 files in 1 dirs): Allow tests to register project versions for deletion at tearDown | 06:30 |
| Github | mantisbt: master Robert Munteanu * 78c2e76 (1 files in 1 dirs): Add tests for creating issues with version set ... | 06:30 |
| Github | mantisbt: master commits cd2325c...78c2e76 - http://bit.ly/bgsjlp | 06:30 |
| Github | mantisbt: master-1.2.x Robert Munteanu * e457611 (1 files in 1 dirs): Allow tests to register project versions for deletion at tearDown | 06:30 |
| Github | mantisbt: master-1.2.x Robert Munteanu * 4de2365 (1 files in 1 dirs): Add tests for creating issues with version set ... | 06:30 |
| Github | mantisbt: master-1.2.x commits 31a20df...4de2365 - http://bit.ly/cSlwgY | 06:30 |
| grelot | hi everyone | 09:45 |
| dhx_m | hi | 09:47 |
| kang | hi mantis users ;) | 10:02 |
| kang | i would like to know if there's some way of disallowing "CLOSE" on an issue for an access level | 10:02 |
| ynyr | hi | 10:23 |
| ynyr | is there a php function to access custom fields? | 10:23 |
| dhx_m | ynyr: depends on what you mean by "access"... but there should be some functions for you in core/custom_field_api.php | 10:48 |
| ynyr | dhx_m: thanks | 10:49 |
| ynyr | I'll take a look | 10:49 |
| xavier33 | Hi | 10:54 |
| dhx_m | xavier33: hi | 10:54 |
| xavier33 | i need help | 10:54 |
| xavier33 | i want to migrate my mantis 1.2.0a to 1.2.2 | 10:55 |
| xavier33 | but i dont know | 10:55 |
| xavier33 | do you have any link or tuto for this migration ? | 10:55 |
| dhx_m | backup your old installation | 10:57 |
| dhx_m | (database and files) | 10:57 |
| dhx_m | then delete your old directory | 10:57 |
| dhx_m | untar/unzip 1.2.2 | 10:57 |
| dhx_m | copy back your configuration files (config_inc.php, custom_*.inc, etc) | 10:58 |
| dhx_m | then try logging in as the administrator again | 10:58 |
| dhx_m | it'll ask you to run an upgrade script | 10:58 |
| dhx_m | if you run into problems (using MSSQL?) it may be best to upgrade to 1.2.0 before upgrading to 1.2.2 | 10:59 |
| kang | bleh, this source integration is nice but.. wtf with the assumption that people get their svn/git/etc from.. remote server | 11:06 |
| kang | most cases people are going to have a git/svn on the same host | 11:06 |
| kang | =( | 11:06 |
| dhx_m | SVN can be used locally | 11:06 |
| dhx_m | and most of the time you'd have it setup so that a post commit hook notifies MantisBT | 11:06 |
| kang | well i'm doing that now | 11:07 |
| kang | interface was just nicer:p | 11:07 |
| kang | no idea about CLOSE? suppose i gotta hack it up somewhere inside | 11:07 |
| dhx_m | the other VCS plugins should also be able to pull data locally in the future | 11:07 |
| dhx_m | it's just a case of people having time to do it | 11:07 |
| CIA-100 | Mantisbt: hickseydr * r735ddedd01ff / (6 files in 3 dirs): Issue #11826: Remove ajax_api | 11:32 |
| ynyr | hi | 12:25 |
| ynyr | where is the mantis log file? | 12:25 |
| istvanb | hi there | 13:04 |
| istvanb | I have to move a project to under another project (as a subproject). When I did that it looks like it was not a move but rather a mirroring because now I have the same project in two places | 13:05 |
| istvanb | how can I get rid of the original and just show the project once in its new place? | 13:05 |
| nuclear_eclipse | istvanb: right, you need to remove it as a subproject from the old parent | 13:05 |
| istvanb | and I assume in the new place it will display all the issues filed originally to the project | 13:06 |
| nuclear_eclipse | yep | 13:06 |
| istvanb | is this a feature or a bug? | 13:06 |
| nuclear_eclipse | feature | 13:06 |
| istvanb | yes, if I unlink it from the original place it appears only in the new location | 13:08 |
| istvanb | I guess this is what you meant | 13:08 |
| nuclear_eclipse | yep | 13:08 |
| istvanb | thanks man | 13:08 |
| nuclear_eclipse | np | 13:08 |
| istvanb | anyways: today I did a training on some of the users how to use mantis in our company enviroment | 13:08 |
| istvanb | they looked very happy with that | 13:09 |
| istvanb | so from now on we are on an official trial period | 13:09 |
| nuclear_eclipse | congrats | 13:10 |
| istvanb | well | 13:10 |
| istvanb | congrats to you guys! | 13:10 |
| dhx_m | how large is your bugtracker? | 13:13 |
| dhx_m | number of users, issues, etc? | 13:13 |
| istvanb | we have just started it | 13:14 |
| istvanb | so we have 8-10 users | 13:14 |
| istvanb | and only like 15 existing issues | 13:14 |
| istvanb | I will keep this project closed until a month to see how this fits for our needs | 13:14 |
| istvanb | then I will evaluate the results based on the KPI graphs of mantis and also based on user reviews | 13:15 |
| istvanb | if its a success then we will propose this to the higher management | 13:15 |
| istvanb | overall in the company we have about 50-60 potential users | 13:15 |
| dhx_m | I would have thought that 50-60 users would need at least one dedicated person looking after the bug tracker ("change management system" in formal lingo) | 13:20 |
| istvanb | heres the deal | 13:20 |
| istvanb | : | 13:20 |
| istvanb | this is a trial period to make mantis work as a helpdesk system. If it work fine then management has to make a decision. If we want to keep it only for SW then I can manage it | 13:22 |
| istvanb | if they want to expand it to be a global corporate helpdesk system then they have to dedicate a person which can not be me | 13:22 |
| istvanb | I made this very clear to my manager and he is happy with that | 13:22 |
| daryn | nuclear_eclipse around? | 13:36 |
| nuclear_eclipse | hi daryn | 13:45 |
| daryn | hello | 13:46 |
| daryn | i have a plugin question for you | 13:46 |
| nuclear_eclipse | uh oh | 13:46 |
| daryn | should be easy for you i think :) | 13:46 |
| daryn | in our old instance of mantis we customized our email links so that when a user clicks the link it adds the subject and cc's some users | 13:47 |
| daryn | i'm trying to figure out how that works with the plugins as it seems CoreFormatting handles it but not quite following how | 13:47 |
| daryn | i see the email function in CoreFormatting but how/when does that get called? | 13:48 |
| nuclear_eclipse | are you talking about where the plugin automatically converts foo@domain to <a href="mailto:foo@domain">foo@domain</a> ? | 13:48 |
| daryn | yes | 13:48 |
| daryn | so how do i override that? | 13:48 |
| nuclear_eclipse | the email_* functions defined in coreformatting are different | 13:48 |
| nuclear_eclipse | those cover marking up text that's to be sent in an email | 13:48 |
| daryn | ok... | 13:49 |
| nuclear_eclipse | you probably just want to modify core/print_api.php | 13:49 |
| daryn | bah | 13:49 |
| nuclear_eclipse | because the plugin just calls those functions | 13:49 |
| daryn | that's what it was looking like to me but I was hoping I was wrong | 13:49 |
| dhx_m | nuclear_eclipse: is there a preferred way for plugins to load their own JavaScript/CSS/images? | 13:51 |
| nuclear_eclipse | hook the LAYOUT_RESOURCES event and output <link>/<script> tags using plugin_file() to generate the link to stuff in your plugin's files/ directory | 13:53 |
| daryn | dhx_m: nuclear_eclipse: speaking of... should we create a new event and load javascript just before the body tag rather than the head? It seems that is the preferred location for all scripts now. | 13:53 |
| daryn | the closing body tag that is | 13:53 |
| nuclear_eclipse | I'd rather leave it the way it is | 13:54 |
| dhx_m | daryn: I have heard that is the preferred way to load JavaScript too | 13:54 |
| daryn | apparantly the scripts prevent everything else from loading until they finish if they are in the head | 13:54 |
| dhx_m | daryn: however it would impact on performance for users whose browsers can download multiple files at a time | 13:54 |
| dhx_m | the alternative is load the entire <body>... then download the scripts... then execute them | 13:55 |
| daryn | thats the point, with the scripts in the head the browser cannot download multiple files until the scripts are done | 13:55 |
| dhx_m | hmmm so top of the <body> is best? | 13:55 |
| daryn | no bottom of body according to what i've read...from multiple sources which I can't name atm | 13:56 |
| nuclear_eclipse | I'd rather just have a single place to output both JS and CSS stuff... | 13:56 |
| nuclear_eclipse | if you want to move the LAYOUT_RESOURCES event to the end of the page, I don't much care about that, but I don't want to split that event, it'll get confusing and error prone | 13:57 |
| daryn | nuclear_eclipse: i hear that but tbh one of the things that has frustrated me is i have multiple plugins loading both styles and scripts so the styles and scripts are interspersed. that has been a bit confusing to me when debugging | 13:58 |
| daryn | so, in my repo i've modified so all the css links are output just before the </head> in a group and all the scripts are output just before </body> in a group. seems much clear to me | 13:59 |
| nuclear_eclipse | so have your plugin output an HTML comment or something to make it easier for you to find, but having them interspersed shouldn't affect how they work, and leaves less room for people to do the wrong thing | 13:59 |
| dhx_m | nuclear_eclipse: more to the point was where plugins are meant to store CSS/JS? | 13:59 |
| dhx_m | nuclear_eclipse: seeing as plugins could be stored outside the web root | 13:59 |
| nuclear_eclipse | dhx_m: plugin_file() takes care of that | 14:00 |
| nuclear_eclipse | put the file in the plugin's files/ directory, use plugin_file() to generate a URL, and plugin_file.php will handle loading it from the file system and outputting the contents to the client | 14:00 |
| dhx_m | ok so if I were to implement plugin_require_js() it'd use plugin_file() to get the real path (via plugin.php)? | 14:01 |
| dhx_m | ah gotcha | 14:01 |
| nuclear_eclipse | plugin_require_js() ?! | 14:01 |
| dhx_m | yep | 14:01 |
| dhx_m | call it before you send html_top and it'll dump all the JS/CSS includes at once in the header | 14:02 |
| dhx_m | it allows you to selectively include files on a per-page basis | 14:02 |
| nuclear_eclipse | ? I'm so confused | 14:02 |
| dhx_m | which will become more important when/if we ever want to do any fancy JavaScript | 14:02 |
| dhx_m | require_js() and require_css() are two functions I introduced recently | 14:03 |
| nuclear_eclipse | why aren't we just always including js files? | 14:03 |
| nuclear_eclipse | the browser only needs to download them once anyways | 14:03 |
| dhx_m | not every page will use the same JS/CSS files | 14:03 |
| dhx_m | more the point it makes it easy to see which pages use which scripts | 14:03 |
| nuclear_eclipse | I think you're introducing unneeded complexities... | 14:03 |
| dhx_m | it's easy :) | 14:03 |
| daryn | i'm actually having similar issues where i have way too many js/css files loading where they aren't needed | 14:04 |
| * nuclear_eclipse gets an urge to nuke the 1.3 branch and start over with python... | 14:04 | |
| daryn | :) | 14:04 |
| dhx_m | the approach I've taken is somewhat like that of the Linux Kernel | 14:05 |
| daryn | nuclear_eclipse: only I don't know python so you'd be on your own...which might make you happier anyway :) | 14:05 |
| dhx_m | instead of using IFDEF's they call functions that contain the IFDEFS | 14:05 |
| dhx_m | so the ugly conditions are hidden out of the way (and in the event a feature is disabled, the function is skipped by the compiler anyway) | 14:06 |
| dhx_m | nuclear_eclipse: I was thinking C++? :p | 14:06 |
| nuclear_eclipse | bad dhx_m! bad! | 14:06 |
| nuclear_eclipse | how dare you mention the kernel and C++ in the same thought! | 14:07 |
| nuclear_eclipse | don't you know Linus hates C++? | 14:07 |
| dhx_m | :) | 14:07 |
| dhx_m | anyone for C#? :p | 14:07 |
| daryn | only because Linus thinks he is smart...I guess he does have a point there doesn't he :) | 14:07 |
| dhx_m | I think the argument is really... why? What do they gain from moving to C++? | 14:10 |
| dhx_m | and does that outweigh the costs | 14:11 |
| daryn | right, i was just attempting a bit of humor in that C programmers tend to think that C is the language of the gods and those using any other language are mere mortals at best | 14:13 |
| dhx_m | :) | 14:14 |
| dhx_m | do you think they'd like the MantisBT source code? :p | 14:15 |
| nuclear_eclipse | probably not at all | 14:15 |
| daryn | i don't even like MantisBT source code | 14:15 |
| nuclear_eclipse | +1 to that | 14:15 |
| dhx_m | haha | 14:16 |
| dhx_m | I wasn't even here when filters_api.php was written :p | 14:16 |
| nuclear_eclipse | I don't think any of us were here when that beast was written... ;) | 14:17 |
| dhx_m | you can count the length of functions in that file in the 10's of kilobytes | 14:17 |
| daryn | it's going to eventually die a horrific death in the fires of Mount Doom but the road is long and arduous | 14:19 |
| dhx_m | I think we need to get a new Field API done first | 14:19 |
| daryn | nah | 14:19 |
| dhx_m | maybe that's the wrong idea though | 14:20 |
| daryn | fulltext search. no need for field classes | 14:20 |
| dhx_m | it might get annoying if you want to find "version 1" | 14:21 |
| dhx_m | the search would just be "1" wouldn't it? | 14:21 |
| daryn | nope | 14:21 |
| daryn | version_id: 1 | 14:21 |
| daryn | or whatever the operator is | 14:21 |
| daryn | you'll be able to target specific fields if you want | 14:22 |
| daryn | without a huge filter | 14:22 |
| dhx_m | I like the idea... but will it actually replace filter dropdowns? | 14:23 |
| daryn | we might need a simple and advanced where the simple is a single text field and advanced is a list of fields | 14:24 |
| daryn | but I think the advanced would still be just autocompleted text boxes rather than full dropdowns. Maybe textboxes if js is enabled and dropdowns if not ? yuck... | 14:25 |
| dhx_m | I was thinking that with a new Field API we'd know the type of a field | 14:30 |
| dhx_m | and thus we'd be able to create a renderer object that decides how the HTML form will be printed | 14:30 |
| dhx_m | (on a per-field-type basis) | 14:30 |
| dhx_m | so we could show a dropdown box if the number of entries is less than 50 | 14:31 |
| dhx_m | or an autocomplete text box for more than 50 | 14:31 |
| dhx_m | I suspect PHP's OO isn't strong enough to do it nicely though | 14:31 |
| daryn | yeah...that was kinda the direction i was taking before but it still became really complex really fast. | 14:32 |
| daryn | And I think people are getting used to the whole textbox/autocomplete search thing so it's probably preferred anyway | 14:32 |
| dhx_m | it does require JavaScript though... | 14:33 |
| daryn | well the autocomplete does | 14:34 |
| daryn | you could still perform a search from a textbox without autocomplete...I doubt if that will be much of a problem. Usually people know what they are searching for don't they? | 14:35 |
| dhx_m | for some things, yes | 14:39 |
| dhx_m | maybe not for categories, versions, priorities, severities and statuses | 14:39 |
| dhx_m | I think in those cases it may be easier for them to select from a list of options presented to them (orthogonal data) | 14:40 |
| daryn | so maybe those are dropdowns on the advanced filter... | 14:40 |
| dhx_m | yep | 14:40 |
| daryn | you know those could still be populated without knowing the field types though | 14:40 |
| dhx_m | which is why I mentioned the idea of having different renderers for the same field | 14:41 |
| daryn | yeah...there's some thinking and design to do for this... | 14:41 |
| dhx_m | well you'd know it's an enumeration type | 14:42 |
| dhx_m | yep | 14:42 |
| Github | mantisbt: master David Hicks * 735dded (4 files in 2 dirs): Issue #11826: Remove ajax_api ... - http://bit.ly/aHNFU3 | 16:30 |
| paulr_ | moo | 16:41 |
| CIA-100 | Mantisbt: daryn * r9d4204bc4c78 /plugins/XmlImportExport/XmlImportExport.php: Remove invalid unterminated comment string. | 20:58 |
| daryn | paulr still there? | 21:02 |
| paulr_ | moo | 21:05 |
| daryn | whats up with the javascript change? | 21:06 |
| paulr_ | ? | 21:06 |
| daryn | remove minimal_jscss variable commit | 21:06 |
| paulr_ | nuclear_eclipse doesn't want to build compiled files | 21:06 |
| paulr_ | as part of build process | 21:06 |
| paulr_ | so just got minimised versions in javascript did | 21:07 |
| paulr_ | and dumped the variable | 21:07 |
| daryn | 1. it appears some changes that were committed in dev did not get into min because they have now been reverted | 21:07 |
| paulr_ | oh? | 21:07 |
| paulr_ | what we should do is | 21:08 |
| daryn | 2. It's a pain to develop on minimized files so what would be your plan for that? | 21:08 |
| paulr_ | personally | 21:08 |
| paulr_ | i'd split the mantis git up | 21:08 |
| paulr_ | and have a different git module for different things e.g. docbook | 21:09 |
| paulr_ | then as part of build | 21:09 |
| paulr_ | merge them | 21:09 |
| daryn | what does that have to do with this issue? | 21:10 |
| paulr_ | the issue is | 21:10 |
| paulr_ | if we work on 'dev' ones | 21:10 |
| paulr_ | then build 'min' ones | 21:10 |
| paulr_ | and release | 21:10 |
| paulr_ | there could be bugs (from the minifying) | 21:10 |
| paulr_ | IMO, we should ship min files | 21:10 |
| paulr_ | as thats the done thing | 21:10 |
| daryn | seems like we really need both and the build should handle minifying. why did john not want that? | 21:12 |
| daryn | that would prevent this issue where changes were made in dev and not minified | 21:14 |
| paulr_ | personally, i'd like to split the git up or well | 21:17 |
| paulr_ | in hg | 21:17 |
| paulr_ | you can set up a hg module | 21:17 |
| paulr_ | thatp ulls in submodules | 21:17 |
| paulr_ | i.e. have a 'manual submodule' | 21:18 |
| paulr_ | so when you checkout mantis | 21:18 |
| paulr_ | you'd get like | 21:18 |
| paulr_ | mantis_code | 21:18 |
| paulr_ | mantis_manual straight away | 21:18 |
| paulr_ | but it's seem differently | 21:18 |
| daryn | i think that's a tough sell | 21:18 |
| daryn | so...how do we resolve without splitting the repo up. | 21:19 |
| paulr_ | personally, I was gonna build them | 21:20 |
| paulr_ | :) | 21:20 |
| * paulr_ wrote a script to build /min | 21:20 | |
| paulr_ | *however* | 21:20 |
| paulr_ | I think we dont need the config | 21:20 |
| paulr_ | maybe 'git' should have /javascriptrubbisdhjfdsjklfjkl | 21:20 |
| paulr_ | and a script to build /javascript | 21:21 |
| paulr_ | either way, variable is a bit silly | 21:21 |
| daryn | yeah, i don't have a problem with that really. | 21:21 |
| daryn | as long as you don't revert changes :P | 21:21 |
| paulr_ | I didn't realise I had | 21:21 |
| daryn | i know | 21:21 |
| paulr_ | I merged manually one change (aka dhx's) | 21:21 |
| daryn | developer mistake | 21:21 |
| paulr_ | maybe I took an old /min by mistake | 21:21 |
| paulr_ | heh | 21:21 |
| paulr_ | http://www.mantisforge.org/cruisecontrol/buildresults/mantisbt?tab=phpcs | 21:22 |
| paulr_ | I mean | 21:22 |
| paulr_ | i'm building codesniffer/phpdoc rules on each commit | 21:22 |
| daryn | so, personally I'd like to see javascript/dev/our scripts and javascript/minified scripts here | 21:22 |
| daryn | so we always work in javascript/dev/ and the build minifies the files automatically | 21:23 |
| paulr_ | hmm | 21:27 |
| paulr_ | daryn: well, ideally, what i'd like is we have javascript/dev | 21:28 |
| paulr_ | have a script that when javascript/dev changes, it recompiles javascript | 21:29 |
| paulr_ | so basically, changing javascript generates a 2nd commit | 21:29 |
| paulr_ | then on a release build we nuke the javascript/dev | 21:29 |
| daryn | yeah...maybe it should be a precommit hook script that compiles and includes it in the same commit | 21:30 |
| daryn | and don't nuke javascript/dev | 21:30 |
| daryn | then every so often the dev gets removed, added back in, removed....just leave it | 21:30 |
| paulr_ | so right | 21:42 |
| paulr_ | fix up | 21:43 |
| paulr_ | we'll fix up javascript with minified files already | 21:43 |
| paulr_ | and /dev with files to min | 21:43 |
| daryn | paulr_ you doing that tonight? :) | 21:46 |
| paulr_ | well, I think I deleted the compile script yesterday | 21:47 |
| paulr_ | heh | 21:47 |
| daryn | yeah...i just deleted some local changes accidentally...sometimes git is too powerful | 21:47 |
| paulr_ | right | 21:49 |
| paulr_ | lets get a tarball | 21:49 |
| paulr_ | of the /dev folder | 21:49 |
| paulr_ | in fact daryn | 21:50 |
| paulr_ | can I 'undelete /dev' in git? | 21:50 |
| daryn | you can checkout a file at a given point i think | 21:51 |
| daryn | you can revert but don't know if you can partially revert | 21:51 |
| paulr_ | hm | 21:51 |
| paulr_ | i'll try asking a friend | 21:51 |
| daryn | k. i'm heading home but will prolly be on in a bit. | 21:51 |
| daryn | also...probably need a readme or something to let people know not to edit the minified files | 21:53 |
| CIA-100 | Mantisbt: paul * r6b36df3d4dd9 /core/ (3 files in 2 dirs): Fix CodeSniffer Warnings | 22:25 |
| CIA-100 | Mantisbt: paul * r46bc510565d8 /admin/check/ (11 files): Fix PHPDoc Errors | 22:25 |
| Github | mantisbt: master Daryn Warriner * 9d4204b (1 files in 1 dirs): Remove invalid unterminated comment string. | 22:30 |
| Github | mantisbt: master Paul * 46bc510 (11 files in 1 dirs): Fix PHPDoc Errors | 22:30 |
| Github | mantisbt: master Paul * 6b36df3 (3 files in 2 dirs): Fix CodeSniffer Warnings | 22:30 |
| Github | mantisbt: master commits 735dded...6b36df3 - http://bit.ly/bUxGVL | 22:30 |
| CIA-100 | Mantisbt: paul * r55f2ac2091dd / (7 files in 2 dirs): Remove minimal_jscss variable | 23:04 |
| paulr_ | bah no daryn | 23:05 |
| paulr_ | daryn/dhx: mailed you two | 23:19 |
| paulr_ | have I made more of a mess | 23:19 |
| paulr_ | or got what you wanted | 23:19 |
| daryn | getting ready to look at it | 23:19 |
| daryn | paulr_ the change I was missing is there now. not sure about the rest | 23:21 |
| paulr_ | i'll add script in a bit | 23:24 |
| paulr_ | nn for now | 23:58 |
Generated by irclog2html.py