| ../irclogs/#mantishelp.2010-06-23.log | ||
| --- scribe started --- | 00:00 | |
| dhx_m | nuclear_eclipse: wrong commit? | 00:16 |
|---|---|---|
| nuclear_eclipse | sorry, commit 886dccd9a467c892a165e7a755a6b13d0d8ed365 | 00:19 |
| dhx_m | ah yep that's on the TODO list to fix | 00:29 |
| dhx_m | I'm trying to decide at the moment how to handle email notifications on bug_update.php | 00:29 |
| dhx_m | it's not easy :( | 00:30 |
| dhx_m | say someone wants to me notified on change of handler | 00:30 |
| dhx_m | yet they don't want to know when the status changes | 00:30 |
| nuclear_eclipse | yeah, good luck on that one | 00:30 |
| dhx_m | lol I think I'll leave it how it was (mostly) for now | 00:30 |
| dhx_m | ie. precedence of rules... handler > status > update | 00:31 |
| dhx_m | which is rather idiotic at the moment | 00:31 |
| * nuclear_eclipse thinks you opened a gigantic can of worms | 00:32 | |
| dhx_m | but then so too are the email notification settings where half of them don't work (and can't work in many cases) | 00:32 |
| dhx_m | lol | 00:32 |
| dhx_m | I have been thinking for a long time that notifications should tap into the event system | 00:32 |
| nuclear_eclipse | yeah, I would completely agree -- it's just a matter of "how do you do that without pissing off > 50% of current users" | 00:33 |
| dhx_m | so a bundled email plugin responds to EVENT_BUG_UPDATE_POST_COMMIT to send out emails of the changes made | 00:33 |
| dhx_m | well given that email doesn't really work at the moment... I think they're probably already quite annoyed :p | 00:33 |
| dhx_m | you might be interested in #11967 | 00:34 |
| nuclear_eclipse | well, it *does* work, just not the way people expect it to work out of the box; and for anyone who's taken the time to learn and config mantis to do exactly what they want, just about *anything* will be abreaking change for them | 00:34 |
| dhx_m | yep | 00:35 |
| dhx_m | RE #11967 we need to add an event prior to committing a bug update to the database (as well as after) | 00:35 |
| dhx_m | I was thinking of having EVENT_BUG_UPDATE_PRE_COMMIT and EVENT_BUG_UPDATE_POST_COMMIT to replace the current EVENT_BUG_UPDATE event | 00:35 |
| dhx_m | as my new bug_update.php does all validation before making any changes to the database | 00:36 |
| dhx_m | therefore database commits are "guaranteed" (race conditions unavoidable though) | 00:36 |
| dhx_m | whereas before it was possible for some data to be committed (the status change for instance) yet an access check would fail later on in the script for adding a bug note... hence you only get 50% of the changes committed, the other 50% missing | 00:37 |
| nuclear_eclipse | not a fan of those names, but I agree that the events around bug update should be consistent with events for bug report, where REPORT_BUG_DATA allows pre-processing, and standard REPORT_BUG allows post processing | 00:40 |
| dhx_m | ok I'll try that approach instead (will need documentation updates too though) | 00:41 |
| dhx_m | I think I prefer VALIDATE to DATA but it's better to be consistent :) | 00:42 |
| nuclear_eclipse | well, it's more than just validation that it allows | 00:44 |
| nuclear_eclipse | the point is that REPORT_BUG_DATA allows plugins to actually modify the bug data before the database is updated | 00:45 |
| dhx_m | true, it can add/change it too | 00:45 |
| dhx_m | yep | 00:45 |
| nuclear_eclipse | it the case of some proprietary plugins I wrote, we used that to auto-assign issues based on custom field values, as well as updating custom fields based on other changes, like automatically filling in a custom field whenever changing to a certain status | 00:47 |
| nuclear_eclipse | (just for a bit of context) | 00:47 |
| dhx_m | ok cool :) | 01:00 |
| dhx_m | can we also change the parameters of the event where needed? | 01:01 |
| dhx_m | I think EVENT_BUG_UPDATE_DATA should send the existing and updated bug objects to the event handler | 01:01 |
| dhx_m | and EVENT_BUG_UPDATE should receive the updated bug object | 01:02 |
| dhx_m | does that sound reasonable? | 01:02 |
| dhx_m | the catch is we only do a shallow copy (PHP's clone) of the BugData object | 01:03 |
| dhx_m | which at the moment is OK... but in the future if BugData becomes more complex by holding other objects will require a __clone() method on BugData | 01:03 |
| dhx_m | actually... bug_update only modifies primitives anyway, so I can't see it being an issue | 01:04 |
| nuclear_eclipse | dhx_m: just as long as you document any changes made to the events so that it's obvious in what version of mantis it changed, I'm fine with that | 01:05 |
| dhx_m | yep | 01:05 |
| nuclear_eclipse | and by document changes, I mean modify the docbook event reference so that it mentions that behavior was changed in version 1.x.x | 01:06 |
| dhx_m | ok | 01:09 |
| dhx_m | 1.2.2? | 01:09 |
| nuclear_eclipse | that's the problem, I don't like major event changes for minor versions, but I agree that it needs to change... =/ | 01:09 |
| nuclear_eclipse | so yeah | 01:10 |
| nuclear_eclipse | go ahead | 01:10 |
| dhx_m | btw I think I know what we need to do with the new email notification system... create a cache (in the database for now, looking towards memcache support in the future) of every change a user should be notified of | 01:10 |
| dhx_m | and have a cron job (or similar) check once every few minutes to collate those changes into a single email | 01:10 |
| dhx_m | so if someone updates the handler of a bug at 03:45 and then updates the resolution at 03:46... the user will receive an email collating these changes at 03:46+5min as long as no other changes have occurred in the mean time | 01:11 |
| daryn | dhx_m: i like the sound of that | 01:12 |
| nuclear_eclipse | the problem is that it requires some sort of cronjob | 01:13 |
| daryn | yeah...anything is better than what we get now | 01:13 |
| daryn | well...maybe not anything. | 01:14 |
| nuclear_eclipse | right, but Windows servers don't have cronjobs, and I don't like forcing people to set up a cronjob just to deal with email | 01:14 |
| dhx_m | I could have a look at Mediawiki's work queues too | 01:18 |
| dhx_m | I gather those work by running a few items from the work queue on each page request | 01:18 |
| nuclear_eclipse | dhx_m: I still like the idea though -- perhaps it could just work the same as right now, where it does potentially fancy stuff, but then just flushes out all the emails at the end of the page load | 01:18 |
| dhx_m | yep | 01:18 |
| dhx_m | make the timer 0 in other words | 01:18 |
| dhx_m | (in the event there is no cron job) | 01:19 |
| nuclear_eclipse | yeah, just keep using the same config option to tell it whether to rely on a cronjob or not | 01:19 |
| nuclear_eclipse | what you're talking about would also facilitate the much-requested diff-style emails, too | 01:19 |
| dhx_m | daryn: btw hi :) | 01:20 |
| daryn | hello | 01:20 |
| dhx_m | that's a nice side effect | 01:20 |
| dhx_m | one of the main problems I had when using MantisBT last year for a University project was people receiving too many emails | 01:21 |
| dhx_m | so they became less relevant | 01:21 |
| dhx_m | hence why I suggest allowing 5-10min of no changes to a bug before sending a digest | 01:21 |
| nuclear_eclipse | lol, and the biggest complaint when I set up mantis at my old job was not receiving *enough* email :P | 01:21 |
| dhx_m | lol | 01:21 |
| dhx_m | well yeah that too... it's broken :p | 01:21 |
| daryn | everyone at our work pretty much turns them off and uses rss feeds | 01:21 |
| dhx_m | it's either broken and emails aren't sent... or broken and too many emails are sent | 01:21 |
| nuclear_eclipse | dhx_m: I'd also caution to err on the side of sending an email sooner rather than later | 01:22 |
| nuclear_eclipse | people get anxious if they don't get an email immediately after something happens | 01:22 |
| dhx_m | that's true... I'd guess it'd be better left as a user customisable setting | 01:23 |
| dhx_m | "minimum time between notifications on the same bug" or something similar | 01:23 |
| nuclear_eclipse | either way, I'd be more than happy to see the current set of notification options and configuration values get obliterated | 01:23 |
| dhx_m | lol | 01:24 |
| dhx_m | I'm not sure if we should use the event system for notifications or introduce a built-in notification system that plugins can hook into | 01:24 |
| nuclear_eclipse | we just need to make sure there's *some way* of migrating old behaviors to something close enough in the new system, or else you'll hear a *lot* of complaints and bug reports | 01:24 |
| dhx_m | yep | 01:25 |
| dhx_m | [master 43de33b] Refactor bug_update to fix multiple bugs | 01:25 |
| dhx_m | 1 files changed, 405 insertions(+), 254 deletions(-) | 01:25 |
| dhx_m | rewrite bug_update.php (76%) | 01:25 |
| nuclear_eclipse | dhx_m: I'd be more inclined to create a fresh notification API, and allow plugins to hook notification events to enable new notification methods other than email | 01:25 |
| dhx_m | yep I was heading that direction too | 01:26 |
| dhx_m | so MantisBT core has some understanding of notifications | 01:26 |
| daryn | i concur | 01:26 |
| daryn | not that it matters, heh | 01:26 |
| dhx_m | I haven't used git in months... now I have to remember it all heh | 01:27 |
| daryn | either of you looked at filters yet? | 01:27 |
| nuclear_eclipse | lol, I've been a bit too busy chasing david's bugs :P | 01:28 |
| daryn | dang it | 01:29 |
| dhx_m | how was I meant to know the first element in the status enum list was the default (it's not documented at all) :p | 01:29 |
| dhx_m | and no clues as to that being the case hehe | 01:29 |
| nuclear_eclipse | all my mantis time is filled atm with a todo list of stuff I need to accomplish due to a project getting ready for a public release | 01:29 |
| nuclear_eclipse | it was "obvious", duh! | 01:30 |
| nuclear_eclipse | :P | 01:30 |
| dhx_m | lol | 01:30 |
| daryn | i have a class...MantisBugFilter that basically replaces filter api...however, i want to abstract it more and create a class that I can build other filters for that aren't necessarily querying the bug table | 01:32 |
| daryn | i need a name... | 01:32 |
| nuclear_eclipse | MantisFilter? :P | 01:32 |
| daryn | that would be great except thats what you called the abstract field class | 01:33 |
| nuclear_eclipse | no, that's what I called the abstract filter class... | 01:33 |
| dhx_m | with git rebase... when you squash a commit into a previous one... which commit message is used? | 01:33 |
| dhx_m | I guess it lets you edit it anyway | 01:33 |
| nuclear_eclipse | both | 01:33 |
| daryn | but it's for individual fields... | 01:33 |
| daryn | MantisBugFilter is a collection of all the fields in the filter | 01:34 |
| nuclear_eclipse | daryn: I'm confused what you mean -- MantisFilter is what abstracts the ability to a) show a set of inputs to control a filter query, and b) generate a query for the given inputs | 01:35 |
| dhx_m | GRRR I squashed the wrong things | 01:35 |
| nuclear_eclipse | dhx_m: git rebase --abort | 01:36 |
| dhx_m | already done | 01:36 |
| nuclear_eclipse | or check `git reflog` for the old tip's commit hash, and do `git reset --hard <ref>` | 01:36 |
| dhx_m | ah nice, thanks :) | 01:37 |
| daryn | nuclear_eclipse: help me understand... a) show a set of inputs to control a filter query... | 01:38 |
| daryn | this is for one field per instance, correct? | 01:38 |
| nuclear_eclipse | well, one input element, if that's what you mean | 01:39 |
| daryn | so...if it were applied to standard fields, status would be one instance, priority a different instance, etc. | 01:39 |
| daryn | yes | 01:39 |
| nuclear_eclipse | right | 01:39 |
| dhx_m | daryn: I'll commit these changes and backport them... then I'll have a look at filters :) | 01:39 |
| daryn | ok...so i'm talking about a collection of all the input elements on the 'filter' | 01:40 |
| dhx_m | prepare for the worst... :p | 01:40 |
| daryn | to me the filter is the whole thing | 01:40 |
| dhx_m | ... | 01:40 |
| CIA-22 | Mantisbt: hickseydr * r4c7915236c46 /core/bug_api.php: Issue #12096: Add reporter and handler to monitor list on duplicate | 01:40 |
| CIA-22 | Mantisbt: hickseydr * recc102ed24be /core/constant_inc.php: Fix #12094: ERROR_BUG_READ_ONLY_ACTION_DENIED is not obsoleted | 01:40 |
| CIA-22 | Mantisbt: hickseydr * r69c55f958680 /core/bug_api.php: Fix #12095: bug_monitor_copy() should check users exist | 01:40 |
| CIA-22 | Mantisbt: hickseydr * r035a1302792a /bug_update.php: Refactor bug_update to fix multiple bugs | 01:40 |
| CIA-22 | Mantisbt: hickseydr * rfdaef4f8a6cc / (core/constant_inc.php lang/strings_english.txt): Add new error ERROR_BUG_RESOLVE_DEPENDANTS_BLOCKING | 01:40 |
| dhx_m | there we go | 01:40 |
| daryn | but that is semantics | 01:40 |
| dhx_m | I'd use the term "rule" perhaps? | 01:41 |
| dhx_m | a filter consists of multiple rules | 01:42 |
| daryn | dhx_m: i hope that 'prepare for the worst' isn't directed towards filters! | 01:42 |
| daryn | perhaps | 01:42 |
| dhx_m | it wasn't sorry (my bad timing)... it was aimed at those commits | 01:42 |
| daryn | :) | 01:42 |
| daryn | dhx_m i don't suppose you've looked at filters either... | 01:43 |
| daryn | :P | 01:43 |
| dhx_m | not yet sorry, been busy with those changes for 1.2.2 | 01:43 |
| daryn | i want to abstract more but i'd like some feedback | 01:43 |
| daryn | ya, cool | 01:44 |
| dhx_m | I really hate maintaining 2 branches | 01:44 |
| nuclear_eclipse | dhx_m: then don't worry about it, | 01:44 |
| dhx_m | I can see why the Linux Kernel went with their approach :) | 01:44 |
| nuclear_eclipse | we can just push 1.3.0 in a couple weeks and call it a 6 mo release cycle :P | 01:45 |
| dhx_m | lol really? I'm for that haha | 01:45 |
| daryn | let's push filters and break it good! | 01:45 |
| dhx_m | quick, get the beta out today! | 01:45 |
| daryn | btw...i took the MantisTemplate branch and made a new plugin with it to replace phptal plugin | 01:45 |
| nuclear_eclipse | so dhx_m, wanna learn how to build a release? :P | 01:46 |
| daryn | not pushed yet | 01:46 |
| dhx_m | nuclear_eclipse: sure :) | 01:46 |
| dhx_m | actually I don't have a non-expired GPG key at the moment | 01:46 |
| dhx_m | still TODO pending my new email address | 01:46 |
| nuclear_eclipse | well, I can just do the tag myself | 01:47 |
| dhx_m | thanks for the config from before ;) | 01:47 |
| dhx_m | I don't mind posting/etc | 01:47 |
| nuclear_eclipse | step 1) figure out everything noteworthy that's changed between 1.2.x and 1.3.0-dev | 01:48 |
| nuclear_eclipse | step 2) write up release notes in doc/RELEASE with a high level overview of those changes, and remove the old 1.2.x release notes | 01:48 |
| dhx_m | RELEASE NOTES: blame daryn :p | 01:49 |
| nuclear_eclipse | lol | 01:49 |
| daryn | whaaaa? | 01:49 |
| dhx_m | actually blame me for the new bug_update() :p | 01:49 |
| dhx_m | filters ;) | 01:49 |
| dhx_m | daryn: do I need remotes/daryn/filter-constants | 01:51 |
| daryn | we should probably get the Ajax call on bug report removed first...it breaks collapse js | 01:51 |
| daryn | no | 01:51 |
| daryn | filters | 01:51 |
| nuclear_eclipse | step 3) commit the new release notes, and update the codebase to reflect the next designated release version | 01:51 |
| nuclear_eclipse | in this case, 1.3.0-beta1 ? | 01:52 |
| daryn | going straight to beta, eh? | 01:52 |
| nuclear_eclipse | meh, it's not like mantis doesn't have a giant base of stable code... | 01:53 |
| nuclear_eclipse | IMO, alpha is generally reserved for completely new codebases, or times when a huge portion of the release has been untested | 01:53 |
| dhx_m | filters? :p | 01:54 |
| daryn | yeah... | 01:54 |
| daryn | uh huh | 01:54 |
| * nuclear_eclipse pulls up github to look at filters | 01:54 | |
| dhx_m | btw 1.2.0 was only 3 months ago | 01:54 |
| nuclear_eclipse | ? | 01:55 |
| nuclear_eclipse | really? | 01:55 |
| dhx_m | so perhaps we should make it a quarterly release | 01:55 |
| dhx_m | Mon, 22 Feb 2010 20:21:46 +0000 (15:21 -0500) | 01:55 |
| nuclear_eclipse | jreese@mach ~/workspace/mantisbt ±master-1.2.x » git show release-1.2.0 | 01:55 |
| nuclear_eclipse | tag release-1.2.0 | 01:55 |
| nuclear_eclipse | Tagger: John Reese <jreese@leetcode.net> | 01:55 |
| nuclear_eclipse | Date: Mon Feb 22 15:29:36 2010 -0500 | 01:55 |
| daryn | this will blow everyone's mind after the last release | 01:55 |
| nuclear_eclipse | that's more than 3 months ago.. | 01:55 |
| dhx_m | lol | 01:55 |
| dhx_m | 2 years from 1.1.x to 1.2.x and 3 months to 1.3.x | 01:55 |
| dhx_m | indeed it is | 01:55 |
| daryn | barely | 01:56 |
| dhx_m | http://git.mantisbt.org/?p=mantisbt.git;a=summary must be wrong | 01:56 |
| nuclear_eclipse | well, in all truthfulness, I'll giwe it some slack since it's exactly four months, but if it still says three tomorrow... | 01:57 |
| dhx_m | ah I see :) | 01:57 |
| nuclear_eclipse | either way, two months from beta to rc to final seems reasonable... | 01:57 |
| dhx_m | headline features would be... filters? | 01:57 |
| daryn | then 1.4 templates in 3 more months? | 01:58 |
| daryn | :D | 01:58 |
| dhx_m | haha get busy :p | 01:58 |
| nuclear_eclipse | daryn: sounds good to me :P | 01:58 |
| dhx_m | I'm up for that, thanks for offering to do all the work too :) | 01:58 |
| nuclear_eclipse | http://www.mantisbt.org/bugs/changelog_page.php?version_id=101 | 01:58 |
| dhx_m | ah so I did make a few minor user noticeable changes | 01:59 |
| nuclear_eclipse | dhx_m: seems like the highlight is "lots of small, but progressive changes" | 01:59 |
| dhx_m | fancy new page footer too | 01:59 |
| daryn | if we're going to put filters in i need to add a bunch of filter bugs that will be fixed | 01:59 |
| dhx_m | lol | 02:00 |
| nuclear_eclipse | dhx_m: I can name a few important fixes for 1.3 though | 02:00 |
| dhx_m | by how many megabytes does nuclear_eclipse need to expand the mantisbt.org database server by to accommodate these bugs? | 02:00 |
| nuclear_eclipse | well, before an official 1.3 | 02:00 |
| dhx_m | yep | 02:01 |
| daryn | no, i mean target exisitng bugs for the release and mark them fixed | 02:01 |
| dhx_m | *cough* that preselection of next status feature I blogged about | 02:01 |
| daryn | of course the other might be true also... | 02:01 |
| dhx_m | ah yep | 02:01 |
| nuclear_eclipse | a) version inheritence is incomplete and has a few bad side effects, like roadmap/filter handling, etc | 02:01 |
| nuclear_eclipse | b) new random/crypto stuff is broken by default | 02:02 |
| dhx_m | it's fixed now | 02:02 |
| nuclear_eclipse | ah | 02:02 |
| dhx_m | ie. Windows is made to be insecure as there is no other working option | 02:02 |
| dhx_m | it uses the weak pseudo-random number generator | 02:03 |
| dhx_m | oh it's not fixed | 02:05 |
| nuclear_eclipse | I didn't think so :P | 02:05 |
| dhx_m | (for Windows) | 02:05 |
| nuclear_eclipse | c) we need to document changes that plugin authors need to be aware of when making plugins compatible with 1.3 | 02:06 |
| nuclear_eclipse | d) rewrite admin guide :P | 02:06 |
| daryn | filters will affect that too | 02:06 |
| dhx_m | nuclear_eclipse: db_get_table hah | 02:07 |
| nuclear_eclipse | ;) | 02:07 |
| daryn | yeah... | 02:07 |
| nuclear_eclipse | daryn: filters is branched from master, right? | 02:09 |
| daryn | yes | 02:09 |
| daryn | although...i may not have your changes from today in it. don't remember | 02:09 |
| nuclear_eclipse | k, gonna pop a diff onto my phone so I can review it later | 02:09 |
| daryn | cool. thx | 02:10 |
| nuclear_eclipse | tsk tsk daryn, git is highlighting all your bad whitespacing... :P | 02:11 |
| daryn | yeah...i try to remove it all but you know i missed some | 02:11 |
| nuclear_eclipse | `git diff master...daryn/filters` highlights bad spacing in red for me | 02:12 |
| daryn | it does for me too but sometimes i get in a hurry | 02:12 |
| * nuclear_eclipse wags his finger at daryn | 02:12 | |
| nuclear_eclipse | anywho, bedtime for me | 02:12 |
| daryn | i usually check all that and clean it up before pushing but was in a hurry for you guys | 02:13 |
| daryn | of course it didn't help any | 02:13 |
| daryn | :P | 02:13 |
| nuclear_eclipse | dhx_m: you going to be around in ~10hours? | 02:13 |
| dhx_m | yep | 02:13 |
| nuclear_eclipse | k, I'll ping you when I get to work | 02:13 |
| dhx_m | will try and have lots of bugs fixed by then | 02:13 |
| dhx_m | ok, cya then :) | 02:13 |
| nuclear_eclipse | awesome | 02:14 |
| nuclear_eclipse | cheers | 02:14 |
| dhx_m | 'night | 02:14 |
| daryn | gnite | 02:15 |
| daryn | dhx_m you in australia? | 02:15 |
| dhx_m | daryn: yep | 02:15 |
| daryn | my wife tells me we're going there next year. her friend is getting married there | 02:16 |
| dhx_m | just be careful of the sharks, world's most poisonous snakes, dropbears, poisonous spiders, lethal jellyfish, etc :p | 02:17 |
| daryn | :) | 02:17 |
| daryn | don't say snakes...she might change her mind | 02:17 |
| dhx_m | hah | 02:17 |
| dhx_m | I even forgot crocodiles from that list duh :p | 02:18 |
| daryn | hehe | 02:18 |
| dhx_m | are you using Windows at the moment? | 02:22 |
| daryn_ | no...linux only | 02:27 |
| CIA-22 | Mantisbt: hickseydr * r3436d148684f /core/crypto_api.php: Use insecure built-in PRNG on Windows (no other options available) | 02:28 |
| dhx_m | yep same here, I'll ask paul later to check the latest version of PHP 5.3 on Windows with openssl_random_pseudo_bytes() | 02:28 |
| daryn | dhx_m any chance when reworking notifications you can make it so a user can completely remove notification regarding a specific bug even if they have written bugnotes? | 02:53 |
| dhx_m | that sounds to me like the monitor list should act as both a whitelist and blacklist | 02:54 |
| daryn | maybe change it so when adding a note they are added to the monitor list and only use that for sending emails | 02:54 |
| dhx_m | also while notifications are high priority... so too is theming :) | 02:54 |
| daryn | yeah... | 02:54 |
| dhx_m | personally I'd like to focus on templating/theming for the next MantisBT release | 02:55 |
| dhx_m | as I think it's something that may interest developers in helping out the MantisBT project | 02:55 |
| dhx_m | it's easier work writing HTML templates than it is rewriting core parts of Mantis :) | 02:55 |
| CIA-22 | Mantisbt: hickseydr * r373d998a1aab /bug_update_advanced_page.php: Issue #12097: Remove usage of update_mode parameter | 03:25 |
| CIA-22 | Mantisbt: hickseydr * r981621614d60 / (43 files in 4 dirs): Fix #12085: Remove $g_allow_close_immediately | 03:25 |
| socorropc | hello good evening. I've recently upgraded my mantis installation from 1.2rc3 up to 1.2.1. I upgraded the application, and everything is working great except from the "View Issue Detail" page which is not showing up the issue detail (numbre of issue, assigned to, etc.) Only shows custom fields I created... Any ideas? I guess it might be a configuration parameter which I might be using incorrectly... | 03:26 |
| socorropc | "View Issue Detail" page which is not showing up the issue detail (numbre of issue, assigned to, etc.) Only shows custom fields I created... Any ideas? | 03:44 |
| CIA-22 | Mantisbt: hickseydr * r0b6540cb1e76 / (3 files in 3 dirs): Fix #11967: Fix bug update events (both pre and post commit) | 04:10 |
| dhx_m | socorropc: screenshot please? | 04:10 |
| socorropc | how can I give them to you? | 04:11 |
| dhx_m | just upload them to a free image hosting site perhaps? | 04:16 |
| socorropc | give me 1 sec... | 04:16 |
| socorropc | alright, dhx_m, please have a look @ http://www.4shared.com/photo/DoIJjwKD/newmantis.html & http://www.4shared.com/photo/PVu1XYON/oldmantis.html | 04:29 |
| CIA-22 | Mantisbt: hickseydr * r11fb95de538e /bug_reminder_page.php: Fix #11981: Factor in view status when showing user monitor list | 04:29 |
| dhx_m | hmmm | 04:31 |
| dhx_m | ah | 04:31 |
| socorropc | ? | 04:31 |
| dhx_m | $g_bug_view_page_fields | 04:32 |
| dhx_m | check config_inc.php for anything relating to which fields to show on view_bug_page | 04:33 |
| dhx_m | it changed from 1.2.0RC2 => 1.2.0 | 04:33 |
| socorropc | will have a look at it and let you know... give me a couple of minutes | 04:37 |
| socorropc | I searched view_bug in config_inc.php. only have $g_my_view_bug_count=10... nothing about view_bug_page neither in config_defaults... | 04:46 |
| dhx_m | are you sure you upgraded correctly? | 05:08 |
| dhx_m | ie. backup old directory, extract new version into a clean directory | 05:08 |
| dhx_m | then copy over your old config_inc.php and custom_ pages? | 05:08 |
| socorropc | pretty, I received no error messages, no warning, etc... | 05:09 |
| socorropc | followed the upgrade instructions in the website | 05:09 |
| siebrand | dhx_m: in the commits where you removed that message: there is no need to remove messages from languages other than English if you don't want to. This will be done automagically each time I export translations. | 06:21 |
| dhx_m | siebrand: ok thanks for the heads up, I might use that approach from now on | 06:21 |
| dhx_m | I was previously using sed so it wasn't any time out of my day :) | 06:22 |
| dhx_m | siebrand: I was talking to nuclear_eclipse before and I think we may be pushing for a 1.3.0 release in the next month or two | 06:22 |
| siebrand | dhx_m: oh, nice! | 06:23 |
| siebrand | dhx_m: guess I'll have to change the supported version from master-1.2.x to master-1.3.x then... | 06:23 |
| dhx_m | siebrand: aiming for a ~6 month release cycle so we're not maintaining two vastly different branches of MantisBT for a long time | 06:24 |
| siebrand | sounds like a plan. | 06:24 |
| dhx_m | the problem I see at the moment (and I'm sure you notice it too with translations) is that it is hard/complex/time consuming to deal with two branches which are quite different to each other | 06:24 |
| siebrand | dhx_m: I don't support multiple branches at the moment. | 06:25 |
| siebrand | dhx_m: that's because of technical limitations. If I could, it wouldn't be a big deal. | 06:25 |
| dhx_m | is that related to the language changes Paul keeps talking about? or is it limitations on the translatewiki end? | 06:26 |
| siebrand | dhx_m: limitations in our backend. | 06:26 |
| dhx_m | to be honest I don't see us changing strings in minor releases in the future if we speed up our major release cycle | 06:28 |
| siebrand | dhx_m: on an abstract level we have File Format Support classes (FFS). Those classes have features. The features we use for branches are only supported in one particular FFS, the one for MediaWiki core. | 06:28 |
| siebrand | I'd like that to be more generic, and that's on a wish list, but there are higher priorities all the time. | 06:29 |
| siebrand | FOSS projects can always use more developers ;) | 06:29 |
| dhx_m | do you have a link to the source code... it's something I could be able to help with | 06:29 |
| dhx_m | if it isn't 10,000 LOC complexity :) | 06:30 |
| dhx_m | the reason I'm interested is that there are plans to add templating/a new language subsystem/etc to MantisBT (probably using PHPTAL at this stage) | 06:31 |
| dhx_m | PHPTAL has an awareness of i18n built in and all we'd have to do is plug it into our lang/strings_* formatted files | 06:33 |
| siebrand | dhx_m: our code is here: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Translate/ | 06:35 |
| siebrand | dhx_m: specific code we use for MantisBT Is http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Translate/ffs/PhpVariables.php?view=annotate and http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Translate/groups/Mantis.php?view=annotate | 06:36 |
| dhx_m | siebrand: you've been busy writing code, I don't remember it being so well organised/neat a year ago :) | 06:36 |
| siebrand | dhx_m: people learn, and as no one else did it, I had to learn it... | 06:37 |
| dhx_m | siebrand: I very much like the idea of FFS where you can easily integrate different file formats by writing a simple class | 06:37 |
| siebrand | dhx_m: Nikerabbit from #mediawiki-i18n has written most of our extension's code. | 06:38 |
| siebrand | dhx_m: for the PHPVariables FFS there are two changes to be made. | 06:39 |
| siebrand | dhx_m: The current FFS needs to be migrated to a new cached serialised structure that reduces parsing. | 06:39 |
| siebrand | dhx_m: all base classes are there already, it's just the FFS specifics that needs to be put into a new class. | 06:40 |
| siebrand | dhx_m: config of the message groups is then done using YAML. | 06:40 |
| siebrand | dhx_m: the second is adding Mangler support, and I think with a specific extensions, so that messages can be inherited from another group, based on another template. Nikerabbit can explain if you really want to work on it :) | 06:41 |
| dhx_m | well I like the simplicity of the YAML formatted files for MantisBT plugins | 06:41 |
| dhx_m | as I had plans to rip some of the core functionality out of MantisBT into core plugins (as was done with graphs) | 06:42 |
| dhx_m | so it should be pretty easy for me to send you some .yml's if that eventuates | 06:42 |
| dhx_m | not that those files are the main problem... I imagine it's more work at your end setting up projects/etc on translatewiki? | 06:43 |
| dhx_m | I'm looking at http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Translate/groups/MediaWikiExtensions.php?view=markup | 06:43 |
| siebrand | dhx_m: the technical side is no longer the challenge if FFS support is there. | 06:43 |
| dhx_m | to see how extensions are handled in MediaWiki... quite different I see | 06:44 |
| siebrand | dhx_m: MediaWiki extensions is a different beast. More features (like magic files and special page aliases), and volume. | 06:44 |
| siebrand | dhx_m: A better example is to look at the YAML for Shapado. | 06:45 |
| siebrand | dhx_m: that's what the MantisBT config should look like in the future. | 06:45 |
| dhx_m | nice, thanks :) | 06:46 |
| Ximera | Добрый день. Вчера я произвел обновление своего MantisBT до версии 1.3.0, но столкнулся с проблемой. Из имеющейся документации я понял, что записать в параметр g_crypto_master_salt. Может кто знает, что нужно записать в этот параметр? Microsoft IIS 7.0 MantisBT 1.3.0 | 07:01 |
| Ximera | Good afternoon. Yesterday I made a MantisBT update to version 1.3.0, but encountered problem. From the available documentation, I realized that to write a parameter g_crypto_master_salt. Maybe someone knows what to write in this setting? Microsoft IIS 7.0 MantisBT 1.3.0 | 07:02 |
| dhx_m | Ximera: hi | 07:09 |
| dhx_m | Ximera: you need to create a randomly generated value for $g_crypto_master_salt in config_inc.php | 07:09 |
| dhx_m | Ximera: this value is kind of like a private key for MantisBT | 07:10 |
| dhx_m | Ximera: it is used when generating passwords, CSRF tokens, etc | 07:10 |
| Ximera | sorry, how generate master_salt? | 07:15 |
| dhx_m | Ximera: a random number generator... wait a sec and I'll find out how you do it on Windows | 07:17 |
| Ximera | Sorry, David, you have not forgotten about me? :) | 07:32 |
| dhx_m | I've been trying to find an inbuilt way in Windows to pull random data from CryptoAPI | 07:32 |
| dhx_m | but it seems like it's only usable if you write your own C++/.NET application to use this library | 07:33 |
| dhx_m | Ximera: you can just keyboard mash out a "random" value yourself but it isn't the ideal approach to use | 07:36 |
| Ximera | it's don't work :( i get ERROR_CRYPTO_CAN_NOT_GENERATE_STRONG_RANDOMNESS | 07:37 |
| Ximera | "Unable to find a source of strong randomness for cryptographic purposes." | 07:38 |
| dhx_m | ah yes that has been fixed as of a few hours ago | 07:39 |
| dhx_m | http://git.mantisbt.org/?p=mantisbt.git;a=commit;h=3436d148684f0216a565b7d744eef98fc3eac7e9 | 07:40 |
| dhx_m | you can backport that patch to 1.2.1 if you like | 07:40 |
| Ximera | thanks :) | 07:40 |
| dhx_m | "fixed" is used loosely as it actually disables strong crypto PRNG on Windows | 07:42 |
| dhx_m | nothing that a normal MantisBT user would really need to worry about though | 07:42 |
| dhx_m | almost killed Projax and replaced it with jQuery Autocomplete :) | 08:33 |
| dhx_m | this new system will be 1000000000000 times better as all you have to do is add the "autocomplete" class to the input type="text" field you want to add autocomplete support for | 08:35 |
| dhx_m | then you just need to add a function to xmlhttprequest_api.php to send the JSON data | 08:35 |
| kirillka | hi all | 12:43 |
| kirillka | nuclear_eclipse | 12:44 |
| kirillka | nuclear_eclipse: git can import cvs repository? | 12:44 |
| nuclear_eclipse | kirillka: I don't know about CVS, but it can import from an SVN repo | 12:53 |
| kirillka | nuclear_eclipse: I see drupal work with cvs, and don't migrate to svn or dvcs. I don't want install cvs or svn client | 12:55 |
| nuclear_eclipse | afaik, if they use CVS, you're gonna need to install CVS | 12:57 |
| nuclear_eclipse | or find a project that uses SVN or Git | 12:57 |
| kirillka | O! I found on github mirror for git.mantisfr.org | 13:07 |
| dhx_m | nuclear_eclipse: any good with jQuery autocomplete? :) | 13:13 |
| kirillka | dhx_m: nice to see you | 13:14 |
| dhx_m | the documentation on autocomplete sucks :p | 13:14 |
| dhx_m | kirillka: hi :) | 13:14 |
| rolfkleef | cvs -> git: a friend of mine does that (works on drupal stuff) but seems not to work well with branches in CVS (but if you only use HEAD it seems to work ok bidirectionally) -- can ask what he uses | 13:16 |
| rolfkleef | drupal will move to git when they start working on version 8 | 13:16 |
| kirillka | rolfkleef: Thanks. I want give only HEAD revision, but I found mirror with git of cvs repository. | 13:18 |
| nuclear_eclipse | dhx_m: unfortunately not | 13:21 |
| dhx_m | ok thanks :) | 13:22 |
| dhx_m | I am returning the following JSON: | 13:22 |
| dhx_m | 7 | 13:22 |
| dhx_m | ["abc"] | 13:22 |
| dhx_m | 0 | 13:22 |
| dhx_m | I don't know why the numbers are there (from json_encode() in PHP) | 13:22 |
| nuclear_eclipse | dhx_m: try doing a file_put_contents("/tmp/json", print_r($data,true)) on your data before you put it through json, and make sure you have an appropriate data structure? | 13:23 |
| dhx_m | oh it's OK... it's the HTML chunked transfer encoding at work | 13:27 |
| dhx_m | it works :) | 13:41 |
| dhx_m | just need to work out a way of getting $(this) to work inside $().autocomplete | 13:42 |
| kirillka | daryn: mo | 13:42 |
| daryn | morning | 13:42 |
| daryn | :) | 13:42 |
| daryn | or evening as may be the case | 13:42 |
| dhx_m | daryn: hi | 13:42 |
| daryn | hallo | 13:43 |
| daryn | what did i miss? | 13:43 |
| daryn | you converting projax autocomplete to jquery? | 13:44 |
| dhx_m | yep, almost done | 13:44 |
| daryn | yay! | 13:44 |
| daryn | now i don't have to | 13:44 |
| dhx_m | $('input.autocomplete').autocomplete({ | 13:44 |
| dhx_m | source: function(request, callback) { | 13:44 |
| dhx_m | so any input field with the "autocomplete" class will work for now | 13:45 |
| daryn | great | 13:45 |
| dhx_m | I'm not sure if the attribute selector is allowed there | 13:45 |
| daryn | where? | 13:45 |
| dhx_m | but... the problem is I need the name attribute of the input field which the autocomplete event fired on | 13:45 |
| dhx_m | ie input[type=text].autocomplete | 13:46 |
| daryn | you can get that... | 13:46 |
| dhx_m | alert($(this).attr('name')); | 13:46 |
| dhx_m | undefined | 13:46 |
| daryn | yeah... it's your setup i think | 13:46 |
| dhx_m | I assume $(this) refers to the callback for the source: thingy | 13:46 |
| daryn | is the code where i can look at it? | 13:46 |
| dhx_m | it can be :) | 13:47 |
| daryn | this changes constantly in js | 13:47 |
| daryn | let me take a look at it | 13:47 |
| daryn | you can do.... $(input.autocomplete').each( function() { alert($(this).attr('name')); $(this).autocomplete( ... | 13:49 |
| dhx_m | $('input.autocomplete').autocomplete({ | 13:51 |
| dhx_m | source: function(request, callback) { | 13:51 |
| dhx_m | $.getJSON('xmlhttprequest.php', {'entrypoint' : 'os_get_with_prefix', 'os' : request.term}, function(data) { | 13:51 |
| dhx_m | var results = []; | 13:51 |
| dhx_m | $.each(data, function(i, value) { | 13:51 |
| dhx_m | results.push(value); | 13:51 |
| dhx_m | }); | 13:51 |
| dhx_m | callback(results); | 13:51 |
| dhx_m | }); | 13:51 |
| dhx_m | } | 13:51 |
| dhx_m | }); | 13:51 |
| dhx_m | I need ($this).attr('name') instead of the 'os' string | 13:51 |
| daryn | right | 13:51 |
| dhx_m | however it isn't defined at that point for some reason | 13:52 |
| daryn | yeah because the this no longer references the input at that point | 13:52 |
| daryn | it's inside the function and the input is not passed into the function | 13:52 |
| daryn | you should be able to use the each above, set a variable for it and then the variable should be in scope for the function...i think | 13:53 |
| daryn | or... | 13:53 |
| dhx_m | hmm | 13:53 |
| dhx_m | http://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.autocomplete.js | 13:54 |
| daryn | this is the plugin you're using? | 13:56 |
| dhx_m | aha | 13:57 |
| dhx_m | http://blog.seanja.com/2010/03/using-the-jquery-ui-autocomplete-widget/ | 13:57 |
| dhx_m | $(this).attr('element').attr('id'); | 13:57 |
| dhx_m | let's see | 13:57 |
| daryn | there you go | 13:57 |
| dhx_m | bingo! | 13:58 |
| daryn | sweet. that's cleaner for sure | 13:58 |
| dhx_m | well almost... | 13:59 |
| dhx_m | var field_name = $(this).attr('element').attr('id'); | 13:59 |
| dhx_m | $.getJSON('xmlhttprequest.php', {'entrypoint' : field_name + '_get_with_prefix', field_name : request.term}, function(data) { | 13:59 |
| dhx_m | my concatenating of strings must be wrong | 13:59 |
| kirillka | dhx_m: is it autocomplete implements in mantisbt? | 14:00 |
| kirillka | will? | 14:00 |
| dhx_m | kirillka: I'm replacing Projax with jQuery Autocomplete | 14:00 |
| dhx_m | so for fields where it makes sense, yes | 14:00 |
| kirillka | good idea | 14:00 |
| dhx_m | and it'll be trivial to work with in the future | 14:01 |
| dhx_m | unlike the kludge that is Projax | 14:01 |
| daryn | dhx_m aren't you supposed to be using $j rather than $? | 14:02 |
| dhx_m | daryn: I chopped out the compatibility... do we want it back? | 14:02 |
| dhx_m | one of the comments indicated it was temporary | 14:02 |
| daryn | oh...is projax totally removed? | 14:02 |
| dhx_m | yes | 14:02 |
| dhx_m | dead | 14:02 |
| daryn | awesome | 14:02 |
| dhx_m | haha indeed | 14:02 |
| dhx_m | just this last bug to go | 14:02 |
| daryn | np. just means i have to update all my plugin scripts | 14:03 |
| daryn | :P | 14:03 |
| dhx_m | I think people expect to work with $() when using jQuery anyway | 14:03 |
| daryn | oh, definitely | 14:03 |
| dhx_m | oh | 14:06 |
| dhx_m | field_name : request.term | 14:06 |
| dhx_m | field_name is treated as a string | 14:06 |
| dhx_m | rather than a variable | 14:06 |
| kirillka | football begin | 14:06 |
| dhx_m | the entrypoint is OK though | 14:06 |
| dhx_m | http://stackoverflow.com/questions/739151/javascript-variable-evaluation-in-a-map | 14:08 |
| dhx_m | stackoverflow to the rescue | 14:08 |
| daryn | dhx_m: filters? :D | 14:26 |
| dhx_m | daryn: not yet :( | 14:37 |
| dhx_m | daryn: almost done now... just need to escape HTML entities with jQuery | 14:37 |
| daryn | :) i figured. sounds like you've been working on good stuff | 14:37 |
| daryn | i'm working on filters now. writing a base class and changing some of property names | 14:38 |
| daryn | so...it will hopefully be a bit cleaner shortly | 14:38 |
| daryn | dhxm: nuclear_eclipse: what if i want plugins to be able to build filters other than adding to the view issues page? the token_api only allows one filter token per user and it uses a constant to define the type...I need more than one and I need to be able to dynamically add them...thoughts? | 14:56 |
| dhx_m | daryn: I guess a new table of filters vs users? | 14:58 |
| dhx_m | daryn: columns include user_id, filter_id, filter_type? | 14:58 |
| dhx_m | filter_type could be "last known filter for view_all_..." or "last known filter for blah_..." or "saved filter for ..." | 14:59 |
| dhx_m | (of course, change the schema to be more correct) :) | 14:59 |
| daryn | well...we have a filter table we could just add the type to but there are two parts to this... | 14:59 |
| daryn | problem is that persistent filters use the php session cookie but temporary filters use the token table...i think i just answered my own question | 15:00 |
| daryn | they are temporary so overwriting because i'm on a different page won't matter. I can use the same token type | 15:01 |
| daryn | but...for the filters table a type... | 15:01 |
| dhx_m | lol 'persistent' using the session cookie? | 15:04 |
| daryn | well...it stores it in the database and passes the id around in the session cookie | 15:04 |
| daryn | the filter table stores both 'current' filters and 'named filters' | 15:05 |
| dhx_m | what JavaScript compressor am I meant to use? | 15:12 |
| daryn | i don't know... i was just using http://javascriptcompressor.com/ | 15:13 |
| daryn | because it was at the top of google query | 15:13 |
| dhx_m | http://refresh-sf.com/yui/ | 15:18 |
| dhx_m | that one seems to work OK too | 15:18 |
| dhx_m | this sucks though... it should be handled by our build script :) | 15:18 |
| daryn | i agree | 15:19 |
| CIA-22 | Mantisbt: hickseydr * rb77ea9cd2333 / (34 files in 9 dirs): Fix #9117: Replace Projax with jQuery UI Autocomplete | 15:21 |
| nuclear_eclipse | dhx_m: feel free to update the build scripts :P | 19:16 |
| nuclear_eclipse | I can always publicly humiliate you later by reverting your changes ;) | 19:16 |
| ToffeePops | Hi, is it possible to stop users from editing an issues description or additional info after an issue has been raised? | 22:02 |
| ToffeePops | The problem is when a user edits (eg) a large description, all we see in the history is 'description updated', so we have to review the description and try to figure out what has changed (i.e without knowing explicitly what has changed, we don't know if it is important or not). | 22:02 |
| ToffeePops | We are trying to stop our users from editing description and additional info fields and get them to always add notes, but we'd like to formalise it a bit... | 22:02 |
| nuclear_eclipse | ToffeePops: in 1.2.x, Mantis keeps track of old revisions to all the long text fields so that you can audit changes to them after the fact | 22:09 |
| nuclear_eclipse | doh | 22:09 |
| nuclear_eclipse | ToffeePops: in 1.2.x, Mantis keeps track of old revisions to all the long text fields so that you can audit changes to them after the fact | 22:10 |
| ToffeePops | nuclear_eclipse: Awesome! Is there anything special that needs to be done to audit changes? | 22:11 |
| ToffeePops | Can anyone do it or only the administrator? | 22:11 |
| nuclear_eclipse | anyone can see the old revisions | 22:12 |
| ToffeePops | fantastic | 22:12 |
| nuclear_eclipse | but iirc it's a configurable threshold | 22:12 |
| ToffeePops | But where possible we're trying to encourage people to add notes rather than edit existing ;-) | 22:13 |
| ToffeePops | We're still on 1.1.8 so I guess it's time we updated | 22:14 |
| ToffeePops | Hmmm, I clicked on a link to 1.3.0 changelog to see what else was coming up... and got an app error 1601 :( | 22:16 |
| ToffeePops | URL http://www.mantisbt.org/bugs/changelog_page.php?project=mantisbt&version=1.3.0-dev | 22:16 |
| nuclear_eclipse | http://www.mantisbt.org/bugs/changelog_page.php?project=mantisbt&version=1.3.x | 22:16 |
| nuclear_eclipse | I'd definitely not recommend running 1.3.0 yet though | 22:16 |
| ToffeePops | Yeah no worries, was just curious ;-) just a shame to have a dodgy link on http://www.mantisbt.org/download.php | 22:24 |
| ToffeePops | (Change log link under development section) | 22:24 |
| ToffeePops | BTW, our mantis admin said the reason he hasn't updated was that when he tried 1.2.0 the upgrade spat our sql errors updating the database. He's going to try again shortly with 1.2.1 :-) | 22:26 |
| ToffeePops | s/spat our/spat out/ | 22:27 |
| ToffeePops | nuclear_eclipse: Cool, we're upgraded to 1.2.1... I guess the migration improved :-) | 22:50 |
| ToffeePops | At least we think it's 1.2.1... the version number down the bottom LHS of the screen has been removed o_O ? | 22:50 |
Generated by irclog2html.py