| ../irclogs/#mantishelp.2010-01-17.log | ||
| --- scribe started --- | 00:00 | |
| Jan\ | how do I edit the "report issue" form? | 00:07 |
|---|---|---|
| Jan\ | i specified $g_top_include_page but the logo doesn't change? | 01:16 |
| daryn_ | g_logo_image i think | 01:25 |
| daryn_ | yeah, change the logo url with g_logo_image | 01:25 |
| daryn_ | the html is distributed throughout the code so it's a bit of a pain | 01:27 |
| daryn_ | we're trying to move towards a templating system but it's been difficult to make any progress | 01:28 |
| dhx_m | hi | 01:30 |
| dhx_m | paul__: ADMINISTRATOR is more correct, because that is the default level at which someone can change the config stored in the database | 01:30 |
| daryn_ | hi dhx_m | 01:32 |
| daryn_ | do you know what happened with the require_lib and require_api functions? | 01:34 |
| dhx_m | they're still in place at the moment | 01:38 |
| daryn_ | trying to work on phptal and it suddenly can't find the templates | 01:38 |
| dhx_m | well the direction we're trying to head towards is an OO API where classes are autoloaded as needed | 01:39 |
| dhx_m | afaik | 01:39 |
| dhx_m | my changes are really just designed to make it easier/more reliable to include an API and know that it'll "just work" | 01:39 |
| dhx_m | without having to worry about what "what else do I need to load first" | 01:39 |
| dhx_m | the downside is that coupling may be higher in some places | 01:40 |
| dhx_m | as our API is heavily coupled at the moment (not a good thing) | 01:40 |
| daryn_ | yes | 01:40 |
| dhx_m | for instance, bug_api.php has function calls to dozens of other API ranging from twitter_api to project_api | 01:40 |
| dhx_m | project_api would be expected though :) | 01:40 |
| daryn_ | so has this changed require_once? why would require_once no longer work? | 01:42 |
| Jan\ | how do I edit the "report issue" form? | 01:42 |
| Jan\ | I want to remove "Additional Information" | 01:42 |
| daryn_ | Jan\ if you're using 1.2 you can disable it in config_inc.php | 01:43 |
| daryn_ | remove it from the form anyway | 01:43 |
| dhx_m | Jan\: you need 1.2.x, then check config_defaults_inc.php for the options relating to what fields to show/ask for when reporting, updating and viewing bugs | 01:43 |
| Jan\ | i'm using 1.1.8 | 01:43 |
| Jan\ | the stable | 01:43 |
| daryn_ | check bug_report_page.php | 01:44 |
| Jan\ | thx | 01:44 |
| Jan\ | how do I make some fields default? | 01:47 |
| Jan\ | like a default version | 01:47 |
| daryn_ | in the bug_report.php file the second parameter passed to the gpc functions is default | 01:48 |
| Jan\ | $t_bug_data->version= gpc_get_string( 'product_version', '' ); | 01:49 |
| Jan\ | i put text there? | 01:50 |
| dhx_m | gpc_get_string( 'product_version', 'something' ); | 01:50 |
| dhx_m | where 'something' is the default value... | 01:50 |
| Jan\ | ok | 01:50 |
| dhx_m | note that in 1.2.x this has been fixed more properly by using config_get( 'default_something_value' ) in place of 'something' | 01:50 |
| dhx_m | so you can have a different default for each project | 01:50 |
| Jan\ | $t_bug_data->category= gpc_get_string( 'category', config_get( 'default_bug_category' ) ); | 01:51 |
| Jan\ | whats default bug category? | 01:51 |
| Jan\ | can I change that? | 01:51 |
| dhx_m | yes | 01:52 |
| dhx_m | check config_defaults_inc.php for more information on that setting | 01:52 |
| Jan\ | $t_bug_data->version= gpc_get_string( 'product_version', 'alpha' ); | 02:02 |
| Jan\ | that doesn't work | 02:02 |
| dhx_m | versions are IDs, not strings :) | 02:02 |
| dhx_m | at least in 1.2.x | 02:03 |
| Jan\ | ffs | 02:03 |
| Jan\ | when is 1.2 planned for? | 02:03 |
| dhx_m | just use it now in it's near-release-state | 02:03 |
| dhx_m | it's easily upgraded to the final release version | 02:04 |
| Jan\ | you know all these settings could be edited with http frontend | 02:04 |
| dhx_m | yes | 02:04 |
| Jan\ | so why is it not that? | 02:05 |
| dhx_m | MantisBT is behind when it comes to admin config UI | 02:05 |
| dhx_m | always looking for contributors :) | 02:05 |
| dhx_m | it isn't really that much of an issue as most people prefer editing a text file | 02:05 |
| Jan\ | u want a config ui? | 02:05 |
| dhx_m | "most" = my view of it anyway ;) | 02:06 |
| dhx_m | well we have part of one... it just needs a lot of work | 02:06 |
| Jan\ | editing text files are annoying when the webserver isnt local ;) | 02:06 |
| dhx_m | most users would be editing via ssh with vim/etc | 02:07 |
| dhx_m | or alternatively, have an sftp file system mounted locally on their workstation, from where they can use any UI editor of their choice | 02:08 |
| Jan\ | well its still annoying | 02:09 |
| daryn_ | doh! | 02:11 |
| Jan\ | wanna know why? | 02:12 |
| dhx_m | when you're not the one with access to wwwroot? | 02:12 |
| Jan\ | also that mantis is php/http web based bugtracker... | 02:13 |
| Jan\ | and that you basicly have to do more steps to edit the config files than edit the config from the http mantis admin panel | 02:16 |
| dhx_m | there are some reasons for forcing editing via text files | 02:17 |
| Jan\ | clever name, mantis, btw | 02:17 |
| Jan\ | dhx_m are the reasons to just annoy and waste your time ? | 02:18 |
| dhx_m | more to do with security issues I'd say | 02:18 |
| dhx_m | SQL injection attacks on a database shouldn't let someone escalate the problem | 02:18 |
| Jan\ | well if you look at the other php/mysql software, i.e. forums, they seem ok... | 02:19 |
| dhx_m | which would be possible if we have configuration in the database that lets people change paths, URLs, etc | 02:19 |
| dhx_m | it's something we could fix | 02:19 |
| dhx_m | it just requires a lot of careful attention to make sure it works OK | 02:19 |
| nuclear_eclipse | Jan\: tbh, things like phpbb or wordpress don't exactly have a good track record :P | 02:19 |
| dhx_m | nuclear_eclipse: hi :) | 02:19 |
| Jan\ | nuclear_eclipse yeah but they fix it in the next release :P | 02:19 |
| dhx_m | nuclear_eclipse: any thoughts on changing $g_global_settings to be a whitelist instead of a blacklist? | 02:20 |
| nuclear_eclipse | I'd just settling for being able to make *a release* right now... | 02:20 |
| dhx_m | nuclear_eclipse: and scrap the regex to increase performance? | 02:20 |
| Jan\ | I meant the equivalent of security releases that are more frequent | 02:21 |
| dhx_m | nuclear_eclipse: that way we can also easily make the configuration admin page have a dropdown box of possible config values to modify | 02:21 |
| nuclear_eclipse | I know, just making passive aggressive comments here :P | 02:21 |
| nuclear_eclipse | dhx_m: I dunno | 02:21 |
| Jan\ | I'd use trac but I don't have access to python/perl/etc :P | 02:22 |
| dhx_m | Jan\: MantisBT 1.2.x will be pretty secure (one time form validation tokens, tested against XSS bugs, input validation everywhere (no SQL injection), etc | 02:22 |
| Jan\ | the "clever" webhost of my client decided to turn off ssh access for "security reasons" | 02:24 |
| nuclear_eclipse | my apologies | 02:25 |
| dhx_m | at least they're being honest about their faith in the security of their servers :D | 02:25 |
| Jan\ | so everytime I make a config change I have to go edit files with cPanel file manager | 02:26 |
| dhx_m | ie. they know if they enable SSH access, people will root it | 02:26 |
| dhx_m | because it's misconfigured | 02:26 |
| dhx_m | the least they could do is enable sftp access to your web root | 02:26 |
| Jan\ | I don't know, they actually got this other "security measure" that if you misstype your password 3 times for cPanel access your IP gets blacklisted on their servers | 02:27 |
| nuclear_eclipse | oh god | 02:28 |
| dhx_m | hahaha | 02:28 |
| dhx_m | time to change hosts? | 02:28 |
| Jan\ | so guess what happens if your ISP gives you dynamic IPs and some other person "missed" their password more than 3 times and you end up with that IP? | 02:29 |
| Jan\ | you can't access your website :D | 02:29 |
| nuclear_eclipse | I have that for SSH access on my server, but a) it's only a temporary ban, and b) nobody's logging in with a password except for the very rare occasion when I'm at a PC without my ssh key | 02:29 |
| nuclear_eclipse | oh, and c) the threshold is 5 misses | 02:30 |
| nuclear_eclipse | if you miss you password 5 times in a row, that's most likely no longer an accident :P | 02:31 |
| dhx_m | nuclear_eclipse: do you ever use git interactive add (git add -p)? | 02:31 |
| nuclear_eclipse | yep | 02:31 |
| nuclear_eclipse | all the time | 02:32 |
| nuclear_eclipse | there's actually two versions | 02:32 |
| dhx_m | nuclear_eclipse: do you know if it's meant to work if you just have a single hunk? | 02:32 |
| nuclear_eclipse | -i and -p | 02:32 |
| Jan\ | mantis is like the only php bug tracker :/ | 02:32 |
| dhx_m | nuclear_eclipse: every time I run it, it prints the diff and exits back to my shell straight away (no interactiveness) | 02:32 |
| dhx_m | nuclear_eclipse: git add -i does have a menu... but when you use [p] to patch a file, it also shows a diff and exits | 02:32 |
| nuclear_eclipse | it should run just fine with one chunk, because you should potentially be able to ask git to try and split it | 02:32 |
| dhx_m | yep that is what I was after | 02:33 |
| dhx_m | it's probably a bug with Gentoo's compilation of git... or a mistmatch of versions between Perl and git | 02:33 |
| nuclear_eclipse | perhaps | 02:33 |
| nuclear_eclipse | yet another reason I never use Gentoo :P | 02:33 |
| CIA-22 | Mantisbt: hickseydr * re1d134e7dcb8 /docbook/adminguide/en/configuration.sgml: Fix #11400: Update documentation of $g_view_configuration_threshold | 02:37 |
| dhx_m | it saves me in other ways :D | 02:37 |
| CIA-22 | Mantisbt: hickseydr master-1.2.x * r9b1fbd7766fd /docbook/adminguide/en/configuration.sgml: Fix #11400: Update documentation of $g_view_configuration_threshold | 02:37 |
| nuclear_eclipse | omg, I wish people would really learn to search for their problems before they submit yet another report of the same bug that's been reported 5 times already... | 02:37 |
| dhx_m | which one? | 02:38 |
| nuclear_eclipse | 11402 | 02:38 |
| Jan\ | do you use mantis to trac bugs ? :D | 02:38 |
| nuclear_eclipse | I use four different mantisbt trackers on a regular basis :P | 02:39 |
| nuclear_eclipse | each one configured significantly different than the others | 02:39 |
| dhx_m | nuclear_eclipse: have we fixed that problem? | 02:41 |
| nuclear_eclipse | I'm pretty sure we have | 02:41 |
| nuclear_eclipse | I know I've seen way too many bug reports about in_array, and I'm pretty sure paulr's been through all of them | 02:42 |
| nuclear_eclipse | speaking of which: paul__ thereL | 02:42 |
| nuclear_eclipse | ? | 02:42 |
| dhx_m | nuclear_eclipse: most of these sorts of errors (like the one in #10818) appear to be because someone decided to hack their database themselves, screwing it up :) | 02:42 |
| Jan\ | thats another reason you gotta have http config | 02:43 |
| nuclear_eclipse | there were a few bugs where people had screwed up the param order to in_array, or didn't make sure they were passing an actual array to in_array.... | 02:43 |
| nuclear_eclipse | Jan\: feel free to submit an improved manage configuration setup :P | 02:44 |
| Jan\ | i don't know php, just markup stuff | 02:44 |
| Jan\ | meaning, maybe I could design the UI but that's it | 02:45 |
| dhx_m | nuclear_eclipse: I'm toying with an OO approach to fields at the moment (treat every field as a custom field essentially) | 02:46 |
| nuclear_eclipse | dhx_m: good luck on that :P | 02:46 |
| dhx_m | nuclear_eclipse: I'll need it, yeah :) | 02:46 |
| dhx_m | nuclear_eclipse: the real problem is with how to store database in the database | 02:47 |
| dhx_m | oops... how to store DATA :) | 02:48 |
| Jan\ | lets all watch "A Bug's Life" | 02:49 |
| dhx_m | nuclear_eclipse: does this look valid to you: return is_array( $columns ) ? $columns : array(); | 02:54 |
| dhx_m | ie, return an array with no elements if $columns isn't an array | 02:55 |
| dhx_m | trying to fix the in_array() problem for good :) | 02:55 |
| dhx_m | seems to work from what I can see | 02:57 |
| CIA-22 | Mantisbt: hickseydr * r90d3d4db7306 / (core/database_api.php manage_user_page.php): Fix #10818: MetaColumnNames ADOdb function may return bool value | 03:06 |
| CIA-22 | Mantisbt: hickseydr master-1.2.x * rd6b2fd0939ad / (core/database_api.php manage_user_page.php): Fix #10818: MetaColumnNames ADOdb function may return bool value | 03:06 |
| nuclear_eclipse | umm, sure :P | 03:12 |
| nuclear_eclipse | sry, was on a diff screen working on mail server scripts... :P | 03:12 |
| dhx_m | :) | 03:12 |
| * dhx_m is utterly confused with function project_hierarchy_cache( $p_show_disabled = false ) { | 03:23 | |
| dhx_m | why wouldn't you want to cache disabled projects | 03:23 |
| nuclear_eclipse | dhx_m: when all you need to do is show the project dropdown list on normal pages? :P | 03:24 |
| dhx_m | well, I guess this is more of an issue on the manage_project_* pages | 03:24 |
| dhx_m | nuclear_eclipse: so that means I'll have to call project_hierarchy_cache multiple times on the manage_project_ pages | 03:25 |
| nuclear_eclipse | /shrug | 03:25 |
| dhx_m | ie. we won't know if the cache was built with disabled projects | 03:25 |
| dhx_m | so we have to forcefully regenerate it each time we want to show disabled projects | 03:25 |
| dhx_m | ah | 03:26 |
| dhx_m | $g_cache_show_disabled = null; | 03:26 |
| dhx_m | is already a setting for me | 03:26 |
| nuclear_eclipse | dhx_m: you'll find there are a great many things in Mantis that I just ignore the details of because I don't want to go insane | 03:27 |
| dhx_m | lol | 03:27 |
| dhx_m | looks like I've got to change the project_hierarchy_api for 1.2.x then | 03:27 |
| dhx_m | it is somewhat backwards compatible though | 03:28 |
| dhx_m | as all I have to do is add a new $p_show_disabled parameter to some of the functions | 03:28 |
| dhx_m | to specify if the user wants to consider disabled projects | 03:28 |
| dhx_m | *headache* | 03:45 |
| nuclear_eclipse | see? | 03:50 |
| nuclear_eclipse | I told you | 03:50 |
| dhx_m | I might have fixed it | 03:51 |
| dhx_m | although it looks crap | 03:51 |
| dhx_m | from a software design POV | 03:51 |
| dhx_m | it's horrible to have manage_proj_* pages have to be concerned with calling project_hierarchy_cache() | 03:52 |
| dhx_m | I might be able to remove that actually | 03:52 |
| CIA-22 | Mantisbt: hickseydr * rbf80e9eecc42 / (core/project_hierarchy_api.php manage_proj_edit_page.php): Fix #11402: Project hierarchy cache problem on manage_proj_edit_page.php | 03:54 |
| CIA-22 | Mantisbt: hickseydr master-1.2.x * rdd258c75542e / (core/project_hierarchy_api.php manage_proj_edit_page.php): Fix #11402: Project hierarchy cache problem on manage_proj_edit_page.php | 03:54 |
| CIA-22 | Mantisbt: hickseydr * r443d28a22465 / (5 files in 2 dirs): project_hierarchy_cache function shouldn't be called outside API | 04:04 |
| CIA-22 | Mantisbt: hickseydr master-1.2.x * re8ae3806d158 / (5 files in 2 dirs): project_hierarchy_cache function shouldn't be called outside API | 04:04 |
| CIA-22 | Mantisbt: hickseydr * r391d3e8067f9 /manage_user_page.php: Fix #4654: Preserve sort field and order when changing filter | 04:40 |
| CIA-22 | Mantisbt: hickseydr master-1.2.x * r2c8f64b0bf24 /manage_user_page.php: Fix #4654: Preserve sort field and order when changing filter | 04:40 |
| paul__ | daryn_: moo | 11:06 |
| paul__ | dhx_m: moo even | 11:06 |
| dhx_m | yo | 11:07 |
| paul__ | regarding http://git.mantisbt.org/?p=mantisbt.git;a=commitdiff;h=90d3d4db7306108af7316cf009fd8b8bab3b1680 | 11:08 |
| paul__ | ahh, nm | 11:08 |
| paul__ | http://git.mantisbt.org/?p=mantisbt.git;a=commitdiff;h=443d28a22465752f99996bb67ce82cbf883e8ff7 | 11:09 |
| paul__ | not sure I like this | 11:09 |
| paul__ | the reason for caching it | 11:09 |
| paul__ | was that some of our external api's | 11:09 |
| paul__ | loop through all projects | 11:09 |
| paul__ | the call to project_cache tells it to get all rows from dB | 11:10 |
| paul__ | to save getting them a few/one at a time | 11:10 |
| paul__ | i.e. | 11:11 |
| paul__ | the calls to project_hierarchy_cache where added by me | 11:12 |
| paul__ | when evaluating mantis with ~2000 projects/subprojects | 11:12 |
| paul__ | under xdebug | 11:12 |
| paul__ | to fix performance | 11:12 |
| paul__ | I suspect by removing the calls to project_hierarchy_cache you've just reopened bugs to mantis failing with large numbers of projects :) | 11:12 |
| dhx_m | most of the functions there have an argument | 11:13 |
| paul__ | project_hierarchy_cache caches the whole hierarchy | 11:14 |
| paul__ | first | 11:14 |
| dhx_m | which accept a parameter to decide whether to cache disabled projects too | 11:14 |
| paul__ | when I added those | 11:15 |
| paul__ | http://git.mantisbt.org/?p=mantisbt.git;a=commitdiff;h=3bdff58abc2e8bf0ecf7f949bb21c4dd87149fc3 | 11:15 |
| paul__ | I removed project_cache_hierarchy from core.php | 11:15 |
| paul__ | i.e. we used to cache_all projects in core.php | 11:15 |
| paul__ | which is silly if your just hitting a bug view page in one project | 11:16 |
| dhx_m | yep | 11:16 |
| dhx_m | we don't need it elsewhere either anymore | 11:17 |
| paul__ | why? | 11:17 |
| dhx_m | for this sort of reason: http://git.mantisbt.org/?p=mantisbt.git;a=blobdiff;f=manage_proj_edit_page.php;h=e85e2a7e2ad664632cd4ed6932294393d6baed54;hp=3d951589e0ca530f9aa3e395bc7e7ba5869c2c03;hb=bf80e9eecc420c38a732d2e13ef2b3cb1a6b04d3;hpb=90d3d4db7306108af7316cf009fd8b8bab3b1680 | 11:18 |
| paul__ | but you removed those? | 11:18 |
| paul__ | your missing the point | 11:18 |
| paul__ | - project_hierarchy_cache(); | 11:18 |
| paul__ | + project_hierarchy_cache( true ); | 11:18 |
| paul__ | == cache ALL projects in advance | 11:19 |
| paul__ | hmm | 11:19 |
| dhx_m | then I removed that | 11:19 |
| dhx_m | because the functions within project_hierarchy_api accept a parameter specifying whether you want to include disabled projects | 11:19 |
| dhx_m | obviously for a project dropdown, you don't want to know about disabled projects | 11:20 |
| dhx_m | but for the manage_ pages, you do | 11:20 |
| dhx_m | and I guess on the manage_ pages, you need to have both | 11:20 |
| dhx_m | because the project dropdown may appear on those pages :) | 11:20 |
| dhx_m | (in the header) | 11:21 |
| paul__ | print api | 11:21 |
| paul__ | calls project_hierarchy_inheritance() | 11:21 |
| paul__ | without the project_hierarchy_cache(); | 11:21 |
| paul__ | therefore $p_show_disabled = false | 11:21 |
| paul__ | which means project_hierarchy_inheritance doesn't get called | 11:21 |
| paul__ | theefore $g_cache_project_inheritance is gonna be null | 11:22 |
| paul__ | therefore oreach( $g_cache_project_inheritance[$t_project_id] as $t_parent_id ) { is going to return null | 11:22 |
| paul__ | so unless i'm mistaken | 11:22 |
| paul__ | project_hierarchy_inheritance will now return an empty array | 11:23 |
| dhx_m | +function project_hierarchy_inheritance( $p_project_id, $p_show_disabled = false ) { | 11:24 |
| dhx_m | set the 2nd parameter to 2 to get the full cache (with disabled projects) | 11:25 |
| dhx_m | project_hierarchy_cache() remembers if it has already cached: | 11:25 |
| dhx_m | 1) project fields that are enabled | 11:25 |
| dhx_m | 2) projects that are both enabled and disabled | 11:26 |
| dhx_m | so it won't continually cache the same thing | 11:26 |
| dhx_m | at worst, it could cache enabled projects only | 11:26 |
| dhx_m | then it'd need to go back later and also cache the disabled ones | 11:26 |
| paul__ | wait why do we need the || | 11:27 |
| paul__ | wait | 11:27 |
| paul__ | surely we should drop the if | 11:27 |
| paul__ | and just be doing project_hierarch cache? | 11:27 |
| dhx_m | yeah | 11:27 |
| dhx_m | you're right | 11:27 |
| paul__ | maybe we should really be doing | 11:27 |
| paul__ | $g_cache_project_inheritance[true|false] | 11:28 |
| paul__ | to store if we are showing disabled | 11:28 |
| dhx_m | also project_hierarchy_cache should not pull enabled projects from the database if it already has them | 11:28 |
| paul__ | mm | 11:28 |
| paul__ | that's probably less of an issue | 11:29 |
| dhx_m | it should just pull the disabled projects from the database | 11:29 |
| dhx_m | and append that to the already cached list of enabled projects | 11:29 |
| paul__ | (for the most part, i'd hope we are always using disabled=false | 11:29 |
| paul__ | except on admin pages where we set it to true (sometimes) | 11:29 |
| dhx_m | and all those functions like project_hierarchy_inheritance | 11:29 |
| dhx_m | should actually exclude disabled projects (unless asked to include them) | 11:29 |
| dhx_m | ie. look through the cache, but ignore disabled projects | 11:29 |
| dhx_m | yep | 11:30 |
| dhx_m | I've got 3 major features on the way in a moment (1.3.x) | 11:30 |
| paul__ | I dont like the fact we have a hierarchy api + projects api | 11:30 |
| dhx_m | brb | 11:30 |
| paul__ | which are interlinked | 11:30 |
| paul__ | iirc | 11:30 |
| dhx_m | yeah it's not pretty | 11:30 |
| paul__ | I seem to recall when looking there's all sorts going on | 11:30 |
| dhx_m | not the worst part of Mantis though | 11:30 |
| paul__ | I'm out for lunch but gonna try and sort ldap stuff when i get back this evening | 11:31 |
| dhx_m | :) | 11:31 |
| dhx_m | I really hate it how history_api only has 2 fields to store data in | 11:47 |
| dhx_m | everything you want to log regarding bugnotes (or relationships, etc) needs to have the bugnote_id... and then 2 fields for previous and current values | 11:49 |
| paul__ | right need to go bbl | 11:49 |
| dhx_m | ok | 11:50 |
| CIA-22 | Mantisbt: hickseydr * rda6c133f1d50 / (15 files in 4 dirs): Issue #10884: Improve granularity of bugnote permissions | 12:21 |
| CIA-22 | Mantisbt: hickseydr * rdac9d0aae688 / (4 files in 2 dirs): Issue #11405: Add link to bugnote revisions within bugnote display | 12:21 |
| CIA-22 | Mantisbt: hickseydr master-1.2.x * rb9bd739473f7 /core/ (bugnote_api.php history_api.php): Fix #11403: Bugnote ID not formatted correctly in history (view status) | 12:21 |
| CIA-22 | Mantisbt: hickseydr * r14a00b723578 / (4 files in 2 dirs): Issue #11404: Record dropping of bug revisions in bug history | 12:21 |
| CIA-22 | Mantisbt: hickseydr * re7283356da95 /core/ (bugnote_api.php history_api.php): Fix #11403: Bugnote ID not formatted correctly in history (view status) | 12:21 |
| CIA-22 | Mantisbt: hickseydr * rb4581cdccf2e /core/project_hierarchy_api.php: Remove duplicate checks that are performed in project_hierarchy_cache | 12:30 |
| CIA-22 | Mantisbt: hickseydr master-1.2.x * r4dfa13341720 /core/project_hierarchy_api.php: Remove duplicate checks that are performed in project_hierarchy_cache | 12:30 |
| CIA-22 | Mantisbt: s.mazeland * r592f4d7f981e /lang/strings_english.txt: We have issues and notes. "bugs" and "bugnotes" are nonos! | 13:39 |
| * siebrand slaps dhx_m around a bit with a large trout | 13:40 | |
| * giallu misses bugs... | 15:49 | |
| paul__ | dhx_m: +$g_bugnote_user_edit_threshold = $g_update_bugnote_threshold; | 22:53 |
| paul__ | can we avoid doing that | 22:53 |
| paul__ | so that if we re-order file | 22:53 |
| paul__ | we dont introduce bugs | 22:53 |
| dhx_m | paul__: ok, I'll use the %g_setting% format instead then | 23:14 |
| dhx_m | siebrand: sorry ;) | 23:15 |
| siebrand | dhx_m: don't let it happen again. Next time it's a salmon. | 23:15 |
| dhx_m | siebrand: haha, I still have to fix the use of "Bug" in the revision drop history | 23:16 |
| * siebrand shows an evik grin. | 23:16 | |
| CIA-22 | Mantisbt: hickseydr * re0064ff882e0 /lang/strings_english.txt: Use the word "Issue" instead of "Bug" for revision history message | 23:37 |
| CIA-22 | Mantisbt: hickseydr * r370303ccf84d /config_defaults_inc.php: Allow configuration values to be rearranged in config_defaults | 23:37 |
Generated by irclog2html.py