| *** Joins: paulr__ (~IceChat09@cpc5-enfi19-2-0-cust776.20-2.cable.virginmedia.com) | 03:26 | |
| paulr__ | jreese: moo? | 03:44 |
|---|---|---|
| GitHub160 | [mantisbt] grangeway pushed 3 new commits to master-2.0.x: http://git.io/zXHMlw | 04:30 |
| GitHub160 | mantisbt/master-2.0.x 86448ed Paul Richards: reformatting | 04:30 |
| GitHub160 | mantisbt/master-2.0.x 48d7b23 Paul Richards: Fix logic in category_get_id_by_name and use exceptions instead of $trigger_errors | 04:30 |
| GitHub160 | mantisbt/master-2.0.x fbb5e95 Paul Richards: Port of 7beac566f25dc30ffb3224c2823fee77c9223a1b [dregad]:... | 04:30 |
| paulr__ | jreese: it's not linking changesets | 04:33 |
| GitHub41 | [mantisbt] grangeway pushed 1 new commit to master-2.0.x: http://git.io/MaueJA | 04:44 |
| GitHub41 | mantisbt/master-2.0.x ca388c2 Paul Richards: use exceptions instead of $trigger_errors | 04:44 |
| GitHub163 | [mantisbt] grangeway pushed 1 new commit to master-2.0.x: http://git.io/LkoKxQ | 04:44 |
| GitHub163 | mantisbt/master-2.0.x 2f87420 Paul Richards: use exceptions instead of $trigger_errors | 04:44 |
| GitHub148 | [mantisbt] grangeway pushed 1 new commit to master-2.0.x: http://git.io/FVYYdQ | 04:45 |
| GitHub148 | mantisbt/master-2.0.x b5ec3fe Paul Richards: use exceptions instead of $trigger_errors | 04:45 |
| *** Joins: dregad_ (~dregad@127-233.193-178.cust.bluewin.ch) | 05:02 | |
| dregad_ | jreese - hi | 05:15 |
| dregad_ | seems that the source integration is not picking up the events from github | 05:15 |
| dregad_ | did you get my mail from yesterday ? | 05:15 |
| dregad_ | would appreciate if you could have a look, and maybe give me some pointers on how to go about fixing that | 05:16 |
| dregad_ | i just imported recent changes | 05:31 |
| dregad_ | that created a few changesets | 05:31 |
| dregad_ | but still no idea why we're not getting stuff from github | 05:31 |
| dregad_ | and how to debug that | 05:31 |
| *** Joins: dhx1 (~david@60-241-62-124.tpgi.com.au) | 05:35 | |
| dregad_ | paulr__ also mentioned that his commits to master-2.0.x branch are not appearing on the tracker either | 05:59 |
| dregad_ | e.g. fbb5e95e2b8c7b5360471c633029c0f59d067483 | 05:59 |
| dregad_ | but they used to | 06:00 |
| dregad_ | see http://www.mantisbt.org/bugs/plugin.php?page=Source%2Fsearch&repo_id[]=7&branch[]=master-2.0.x | 06:00 |
| dregad_ | all issues in the tracker are now resolved or closed again | 06:45 |
| dregad_ | i created a tag "2.0.x check" on the ones paulr__ had set to "acknowledged" | 06:46 |
| dregad_ | the e-mail notifications are enabled again | 06:46 |
| dregad_ | as a side note, if like me you were wondering why your newsreader is not showing recent messages to mantisbt-dev list | 06:47 |
| dregad_ | that is probably the reason ==> http://sourceforge.net/blog/mailing-list-archives-in-read-only-mode/ | 06:48 |
| paulr__ | hmm | 06:49 |
| paulr__ | hmm | 06:51 |
| paulr__ | config optiosn | 06:51 |
| paulr__ | dregad: hows your jquery? | 07:01 |
| dregad_ | virtually non-existent | 07:01 |
| paulr__ | ;/ | 07:02 |
| paulr__ | http://stackoverflow.com/questions/14354040/jquery-1-9-live-is-not-a-function | 07:02 |
| paulr__ | i'm trying to work out if in our 2nd case we should use null | 07:02 |
| paulr__ | and what to do in the first case | 07:02 |
| dregad_ | i'm definitely not the right person to ask ;) | 07:03 |
| * paulr__ kicks dhx1 | 07:08 | |
| dregad_ | beating a dead horse ? ;) | 07:13 |
| paulr__ | I asdked someone else for migration line for jquery | 07:14 |
| paulr__ | he's written 10 lines of text in a response | 07:14 |
| paulr__ | obviously know's his stuff but lost me :) | 07:14 |
| dregad_ | did you read the doc ? http://api.jquery.com/live/ about halfway down it gives equivalents for .live | 07:28 |
| paulr__ | so i'm just gonna sulk now about my branch not appearing | 07:34 |
| paulr__ | :) | 07:34 |
| paulr__ | and finish off configuration editor | 07:34 |
| paulr__ | which I can't decide whether it should be a plugin or not | 07:34 |
| dregad_ | should be core imo | 07:36 |
| paulr__ | plugin provides nice way for admin to disable though | 07:36 |
| paulr__ | hence not being able to decide :) | 07:37 |
| dregad_ | then make a config to enable the config of configs :P | 07:37 |
| dregad_ | anyway signing off for now | 07:38 |
| dregad_ | be back later, maybe | 07:38 |
| paulr__ | hmm | 07:38 |
| paulr__ | ;/ | 07:38 |
| dregad_ | i'll check your mails probably tomorrow, or monday back at work | 07:38 |
| GitHub149 | [mantisbt] grangeway pushed 2 new commits to master-2.0.x: http://git.io/vJmjVw | 07:38 |
| GitHub149 | mantisbt/master-2.0.x ae6730a Paul Richards: use exceptions instead of $trigger_errors | 07:38 |
| GitHub149 | mantisbt/master-2.0.x 332da7f Paul Richards: Fix javascript for newest jquery | 07:38 |
| paulr__ | dregad: reminderS!?!?!?! | 07:38 |
| dregad_ | i know, i know | 07:38 |
| dregad_ | kids are screaming now, gotta go | 07:38 |
| paulr__ | cya :) | 07:39 |
| *** Quits: dregad_ (~dregad@127-233.193-178.cust.bluewin.ch) (Quit: If you can't laugh at yourself, make fun of other people.) | 07:39 | |
| *** Joins: Hans_Henrik (~Hans_Henr@90.149.250.68) | 09:09 | |
| *** Quits: Hans_Henrik (~Hans_Henr@90.149.250.68) (Quit: Leaving) | 09:56 | |
| GitHub91 | [mantisbt] grangeway pushed 1 new commit to master-2.0.x: http://git.io/u9aXpw | 11:01 |
| GitHub91 | mantisbt/master-2.0.x 40079b6 Paul Richards: lang_get removal within relationship api | 11:01 |
| GitHub109 | [mantisbt] grangeway pushed 1 new commit to master-2.0.x: http://git.io/qCKRYg | 11:22 |
| GitHub109 | mantisbt/master-2.0.x 15f6a48 Paul Richards: optimise relationship_get_details | 11:22 |
| *** Joins: TerrorBite (~lion@quassel.lethargiclion.net) | 13:43 | |
| TerrorBite | I just submitted a patch :D | 13:43 |
| TerrorBite | http://www.mantisbt.org/bugs/view.php?id=8141 | 13:44 |
| GitHub165 | [mantisbt] grangeway pushed 2 new commits to master-2.0.x: http://git.io/U14zTg | 13:51 |
| GitHub165 | mantisbt/master-2.0.x 3911f09 Paul Richards: Multibyte aware str_pad function | 13:51 |
| GitHub165 | mantisbt/master-2.0.x 763a22c Paul Richards: use get_enum_element where appropriate | 13:51 |
| TerrorBite | I suppose I should fork and make a pull request if I wanted to do it properly though | 13:55 |
| paulr__ | i'm wondering if having an 'own' status in workflow would be better | 13:56 |
| paulr__ | could then get rid of 'allow reporter to reopen', 'allow reporter to close', 'allow reporter to update' with a set what you can do to your own issues | 13:57 |
| TerrorBite | Yeah, that'd make sense. I basically used "allow reporter to reopen/close" as precedent | 13:58 |
| paulr__ | (i'm trying to gradually rewrite mantis in large chunks, as an experiment | 13:59 |
| paulr__ | one of the things i'm gradually not liking is the 1000000000 config options we have | 13:59 |
| paulr__ | which in some cases are not used consistently | 13:59 |
| TerrorBite | I did notice there were a lot of config options | 14:02 |
| TerrorBite | Can you explain to me about the workflow? I can see that "Allow Reporter to close Issue" and co are present on the Workflow Thresholds page, but don't seem to fit in properly | 14:03 |
| TerrorBite | I'm assuming they were just sort of shoehorned in there | 14:04 |
| paulr__ | no idea | 14:04 |
| paulr__ | but in terms of work flow | 14:04 |
| paulr__ | in theory you can get quite fancy with who can see what | 14:04 |
| paulr__ | and what status leads to what | 14:04 |
| TerrorBite | yeah I played around a bit with the status stuff, restricting so that e.g. you can only go to feedback from resolved | 14:05 |
| paulr__ | at the moment, we debating what next version of mantis is | 14:06 |
| TerrorBite | In what way? | 14:06 |
| paulr__ | radical rewrites vs not ;) | 14:07 |
| TerrorBite | aha | 14:07 |
| TerrorBite | you know I'm not sure why reporters can't close their own issues by default. At the start I was confused what the difference between resolved and closed was | 14:08 |
| TerrorBite | But I got the workflow sorted out after that | 14:08 |
| paulr__ | well, I guess the other question is whether you need a 'closed' stuats | 14:09 |
| TerrorBite | so that resolved is basically saying "We think we fixed it, how'd we do?" waiting for the reporter to either reopen, or close it | 14:09 |
| TerrorBite | idea being, only the reporter ought to close an issue (unless it's invalid/spam/etc) | 14:10 |
| TerrorBite | Or if it sits at resolved longer than a month, close it assuming the reporter was satisfied | 14:11 |
| TerrorBite | Of course that's just my use-case and I understand that the power of mantis is being flexible to anyone's needs | 14:11 |
| TerrorBite | But it's a pretty mainstream use-case I'd think | 14:12 |
| TerrorBite | It did lead me to thinking that you ought to be able to leave notes on resolved issues but not closed ones. Then I realised that you can leave a note when changing the status, which is enough, and if further discussion is needed then it ought to be reopened anyway | 14:14 |
| GitHub189 | [mantisbt] grangeway pushed 1 new commit to master-2.0.x: http://git.io/R0REdg | 14:15 |
| GitHub189 | mantisbt/master-2.0.x bdd4325 Paul Richards: Fix up config_workflow_page to work without using lang_get | 14:15 |
| paulr__ | My personal focus is that 1.2.x/1.3.x are "dead", and looking at a 2.x concept | 14:16 |
| paulr__ | and experimenting | 14:16 |
| TerrorBite | Experimenting is good | 14:16 |
| paulr__ | [I use mantis with mssql at work, and adodb isn't as useful as one hoped for different db support] | 14:16 |
| TerrorBite | I'm using mantis as an internal tracker for the admin team of a large Minecraft server | 14:17 |
| paulr__ | what server? | 14:17 |
| TerrorBite | mcau.org | 14:17 |
| paulr__ | i'm guessing no redpower etc? | 14:19 |
| dregad | Just a note re: allowing reporters to update their own | 14:20 |
| paulr__ | if it's a config option i'm gonna stab you | 14:20 |
| paulr__ | ;p | 14:20 |
| dregad | You might want to restrictwhich fields are editable | 14:20 |
| * dregad ducks | 14:20 | |
| paulr__ | slowly fixing up 2.x :) | 14:21 |
| TerrorBite | haha | 14:21 |
| paulr__ | dregad: do you still hate me? ;p | 14:21 |
| TerrorBite | dregad: That would be a good idea, yes | 14:21 |
| TerrorBite | paulr__: It's Bukkit, so nothing that requires client mods | 14:21 |
| TerrorBite | RedPower is <3 though | 14:22 |
| * paulr__ runs his own mc server for a few friends | 14:22 | |
| paulr__ | without mods, people spent hours making stuff | 14:22 |
| paulr__ | with mods, people seem to spend hours making power to get uu matter to get resources for free | 14:22 |
| paulr__ | instead of making pretty buildings | 14:22 |
| paulr__ | dregad: https://github.com/mantisbt/mantisbt/blob/next/application/core/helper_api.php#L118 --> /me isn't sure about that | 14:23 |
| TerrorBite | Ugh yeah, EE2 is not very balanced in my opinion | 14:23 |
| paulr__ | we turned EE off | 14:23 |
| TerrorBite | wait | 14:23 |
| paulr__ | (for that reason) | 14:23 |
| TerrorBite | Yeah I'm getting confused. | 14:23 |
| TerrorBite | So turn off mass fabs too? | 14:23 |
| TerrorBite | I always took joy in building complex sorting machines and other labor-saving devices | 14:24 |
| paulr__ | we turned off mass fabs and left matter fab on from gregtech | 14:24 |
| TerrorBite | I like gregtech actually | 14:24 |
| paulr__ | so you get uu matter at slower rate | 14:24 |
| paulr__ | but we've got 2 people with fusion reactors, and a 3rd going up | 14:24 |
| paulr__ | so infinite power | 14:24 |
| paulr__ | and infnite power in slower matter fab = infinite uu | 14:25 |
| paulr__ | advanced pump in nether = infinite copper/tin | 14:25 |
| paulr__ | etc | 14:25 |
| dregad | Dont want to rain on your parade but you might want to take the minecraft stuff offline ;) | 14:25 |
| paulr__ | hehe | 14:26 |
| TerrorBite | I haven't played much gregtech, was experimenting on a friend's Mindcrack server, but got distracted by Ingress | 14:27 |
| dregad | paulr__ what about get_enum_element? | 14:29 |
| paulr__ | well, the strings | 14:29 |
| paulr__ | should really live somewhere else | 14:29 |
| paulr__ | or well ;/ | 14:29 |
| dregad | I never like the way we are doing enus to begin with | 14:30 |
| paulr__ | :) | 14:30 |
| TerrorBite | maybe if you used a real language! | 14:30 |
| * TerrorBite ducks | 14:30 | |
| paulr__ | want a sledgehammer? | 14:30 |
| TerrorBite | haha | 14:30 |
| dregad | And their localization... that is just a disaster | 14:30 |
| paulr__ | want a sledgehammer? | 14:30 |
| paulr__ | $t_command_caption = sprintf( _( 'Update %1$s' ), lang_get_defaulted( $t_custom_field_def['name'] ) ); | 14:31 |
| dregad | TerrorBite: lol | 14:31 |
| paulr__ | i've been staring at that for about 30 minutes now | 14:31 |
| paulr__ | so If I make a custom field called 'signup' | 14:31 |
| paulr__ | or something | 14:31 |
| paulr__ | i'll probably get "thanks for signingup " in the UI | 14:31 |
| paulr__ | i'm not sure about that ;p | 14:32 |
| TerrorBite | Try it and see? | 14:32 |
| paulr__ | dregad: any thoughts? | 14:33 |
| paulr__ | TerrorBite: there's no segmentation on the strings in the core | 14:33 |
| paulr__ | TerrorBite: so if you used the right custom field name, could get funky results | 14:33 |
| TerrorBite | Fun | 14:35 |
| paulr__ | dregad: reminders? ;p | 14:37 |
| * dregad pretends he did not hear | 14:39 | |
| dregad | Re: the sprintf trick, looks good on paper but as you said will be issues if cf name matches existing string | 14:42 |
| dregad | Maybe with a prefix? | 14:43 |
| paulr__ | [10:30.53] <paulr__> want a sledgehammer? | 14:43 |
| paulr__ | [10:31.07] <paulr__> $t_command_caption = sprintf( _( 'Update %1$s' ), lang_get_defaulted( $t_custom_field_def['name'] ) | 14:43 |
| paulr__ | dregad: I was more thining the pgagfdaskf | 14:43 |
| paulr__ | thinking the lang_get_Default bit on it's own | 14:44 |
| paulr__ | anyway | 14:44 |
| paulr__ | remidners! | 14:44 |
| dregad | What's a 'pgagfdaskf' ? | 14:45 |
| * dregad is confused | 14:45 | |
| paulr__ | $t_custom_field_def['name'] ) | 14:45 |
| paulr__ | [10:43.59] <paulr__> dregad: I was more thining the | 14:45 |
| paulr__ | [10:43.59] <paulr__> dregad: I was more thining the pgagfdaskf | 14:45 |
| paulr__ | [10:44.06] <paulr__> thinking the lang_get_Default bit on it's own | 14:45 |
| paulr__ | that's a irc client | 14:45 |
| paulr__ | not want to copy/paste | 14:45 |
| paulr__ | correctly | 14:45 |
| paulr__ | so anyway | 14:46 |
| dregad | Icechat sucks for copypaste | 14:46 |
| paulr__ | i'm not sure history events on reminders are such a good idea | 14:46 |
| dregad | Whynot | 14:46 |
| paulr__ | read what I wrote in mail | 14:46 |
| paulr__ | i'm thinking of fixing properly by adjusting the db fields/structure | 14:47 |
| paulr__ | we dont add a history event when we send a mail to someone on a new note, so why should we for a reminder | 14:47 |
| paulr__ | it strikes me that the adding history event is because you can fill up 255 bytes in a db column that stores it if you send a lot of reminders | 14:48 |
| dregad | I told you my inbox is swamped in 500+ messages and I'm not gonna clean it up on the blackberry | 14:48 |
| paulr__ | which means that to hit that case, given say <9999 users on the system, you'd need to have 51 people on the reminder | 14:48 |
| paulr__ | and to add 51 rows to the history summary so you can see them all [as we truncate at ~51 if we have 4chars followed by a comma in the 255 byte field] | 14:49 |
| dregad | Yes thats right | 14:49 |
| paulr__ | seems like we'd then need a fix to fix the history summary to not sure 51 rows :) | 14:49 |
| dregad | In fact i fixed a bug on that not too long ago | 14:50 |
| paulr__ | which makes me think that either | 14:50 |
| paulr__ | a) we need to look at limiting the number of people you can "remind" | 14:50 |
| paulr__ | or if we dont like arbitary limits | 14:50 |
| paulr__ | b) looking at the data field and seeing if it makes sense to change what is probably a varchar(255) to a larger varchar to avoid the need of A | 14:50 |
| paulr__ | and if we feel that we need to log in the history table who got a reminder | 14:51 |
| paulr__ | we should probably also log who got emailed on a bugnote being added or who got emailed for monitoring an issue - as monitors/managers/developers etc over time can change | 14:51 |
| paulr__ | if we go for option A or B, we probably dont want to add history entries | 14:52 |
| paulr__ | if we go for option C [aka log who gets mails], we should probably add it to a seperate 'communication log' table so as not to spam the history table for performance later on | 14:53 |
| paulr__ | [and to allow the communication log to be purged by people in the future after 4 months for example] | 14:53 |
| dregad | I like B | 15:00 |
| dregad | Btw adding to history is http://www.mantisbt.org/bugs/view.php?id=2971 | 15:01 |
| dregad | See also http://www.mantisbt.org/bugs/view.php?id=15470 | 15:02 |
| paulr__ | yea, I dont like that set of fixes | 15:02 |
| paulr__ | I think both should be considered more fully | 15:03 |
| paulr__ | so adding in a .15 release seems silly | 15:03 |
| paulr__ | TBH - i more wonder about $g_store_reminders | 15:06 |
| dregad | Increasing field size is probably best - limiting to 255 doesnt make much sense with todays varchar fields | 15:06 |
| paulr__ | i'd probably be inclined to remove that | 15:06 |
| paulr__ | and always store | 15:06 |
| paulr__ | and add a 'send mail to' user option | 15:06 |
| dregad | Agreed | 15:06 |
| paulr__ | so if you really really really did want to mail someone | 15:06 |
| paulr__ | you could click on their name and get a form to fill in | 15:06 |
| paulr__ | I can't really think of a usecase where, you'd not want to store a reminder | 15:07 |
| paulr__ | [and not be able to email or something outside] | 15:07 |
| dregad | Think so too | 15:08 |
| paulr__ | let alone a use case where you'd not want to store a reminder | 15:08 |
| paulr__ | but you'd want to log the fact you'd sent a reminder | 15:08 |
| dregad | Right | 15:08 |
| paulr__ | I want to send you this line of text, but I dont want anyone to see it! | 15:08 |
| paulr__ | including myself or you | 15:08 |
| paulr__ | :) | 15:08 |
| dregad | Lol | 15:09 |
| paulr__ | There is also the scenario where reminders are set to not add the reminded person to the monitored list, i.e. the case where the following config is OFF. | 15:09 |
| paulr__ | $g_reminder_recipents_monitor_bug = OFF; | 15:09 |
| paulr__ | I think the reminder should add a history entry per reminded person. This is independent of adding the target person to the monitor list. | 15:09 |
| paulr__ | ^ quoting victor | 15:09 |
| paulr__ | ok, so you can remind people but not add them to monitor list | 15:10 |
| paulr__ | that maybe makes more sense | 15:10 |
| paulr__ | but even then, I don't know about you but that just says to me, there should be some 'control' on who you can 'remind' | 15:10 |
| paulr__ | in any case, I think we should probably revert the history api change + constant | 15:11 |
| paulr__ | and have a think about what we really want to do | 15:11 |
| paulr__ | and are trying to do | 15:11 |
| paulr__ | so pull or do you disagree? | 15:13 |
| paulr__ | i'm probably inclined to not pull the change into the 2.x branch, and to add a note to upgrade scripts for people to run a manual query to remove the reminder log events when upgrading, and having a proper look at what functionality is available | 15:17 |
| dregad | I have to think about it | 15:18 |
| paulr__ | as I don't really see the point of not storing the reminders | 15:18 |
| dregad | I think in any case its quite unlikely to send a reminder to somany ppl | 15:18 |
| dregad | Can't think of a business case for that | 15:19 |
| paulr__ | if it's a 'reminder', it should really only go to anyone on the issue already | 15:20 |
| paulr__ | "hey, have you forgotton about the patch you was testing?" ==> reminder | 15:20 |
| dregad | I would say in 2.x dont port the fix | 15:20 |
| paulr__ | if it's functionality to add someone / poke someone about an issue, it's not really a reminder | 15:20 |
| dregad | Increase db field size | 15:20 |
| paulr__ | yea, but if you dont 'port the fix', we dont want the history events | 15:20 |
| dregad | And always log reminder in bugnote | 15:21 |
| dregad | No history | 15:21 |
| dregad | How does thatsound | 15:21 |
| paulr__ | still need to look properly / think | 15:21 |
| paulr__ | (the reason it's varchar(255) is because some db's limited varchars to 255 | 15:21 |
| paulr__ | for the mysql/pgsql/mssql that's legacy | 15:22 |
| paulr__ | for oracle/db2... not sure if that's still valid | 15:22 |
| paulr__ | I've never really got the 'send reminder' thing | 15:22 |
| paulr__ | to me, to be 'reminded' about something, you must already be linked to it | 15:22 |
| paulr__ | which i'd say would mean the reminder list of people should only include people that are already involved in the issue | 15:23 |
| paulr__ | but then, whats the point of a reminder :) | 15:23 |
| paulr__ | maybe what we really need is two things | 15:24 |
| paulr__ | a) send reminder - which *only* sends a mail, can only be used on people involved with issue and *never* logs | 15:24 |
| dregad | i dont know db2 but i have varchar 2000 in oracle db | 15:24 |
| paulr__ | b) add note [i.e. the if you have something useful to say] | 15:24 |
| paulr__ | c) invite someone to join an issue [ which contacts people not involved in the issue at the moment] | 15:25 |
| dregad | In fact doc says max size is 4000 http://docs.oracle.com/cd/B28359_01/server.111/b28320/limits001.htm | 15:25 |
| paulr__ | and if you did those 3 things above | 15:25 |
| paulr__ | would you then want to log who you invited/reminded in the history or not | 15:25 |
| paulr__ | :) | 15:25 |
| dregad | Reminder forces sending an email | 15:26 |
| dregad | 'Normal" involvement and resulting email notices can be ignored by user preferences (as you noticed today) | 15:27 |
| paulr__ | on that note, i'm not sure if it should force sending an mail | 15:29 |
| paulr__ | under the spam rules etc now a days, should probably allow someone to opt out from receiving mail | 15:30 |
| dregad | If not, what's the point of the reminder | 15:30 |
| paulr__ | well, if you could view reminders in the system.. | 15:30 |
| paulr__ | i.e. internal flag up | 15:31 |
| paulr__ | could be nice | 15:31 |
| dregad | Does not replace a direct notification | 15:31 |
| * paulr__ nods | 15:32 | |
| paulr__ | but then that comes back to my, to be reminded about an issue, you should already have to have been involved in it | 15:32 |
| paulr__ | atm, I can use the reminder thing to forcibly send an email to you about any issue | 15:33 |
| paulr__ | so it's better to use 'reminder' then to assign it to you | 15:33 |
| dregad | Or youre grangeway and want dhx's opinion on a bug youre working on | 15:33 |
| paulr__ | as if I assign it to you, you might not see it until you log in depending on your settings | 15:33 |
| paulr__ | whereas if I remind you, you definitely get an email | 15:34 |
| dregad | Right | 15:34 |
| paulr__ | re the 'dhx opinion' - thats where I said maybe we need some 'invite someone to issue' functionality | 15:34 |
| paulr__ | i.e. you can invite 1 person at a time | 15:34 |
| paulr__ | "hey, can you look give your input into X" | 15:34 |
| dregad | Thats how i use the feature myself | 15:35 |
| dregad | Dont think i ever added more than 1 pers to a reminder | 15:35 |
| paulr__ | (i'm liking the idea atm of making "reminder"'s only going to people already involved / linked to the issue in some way, and adding an invite thing that allows you to message 1 person at a time | 15:35 |
| dregad | Thats an idea | 15:36 |
| dregad | I like it actually | 15:36 |
| paulr__ | i'm thinking it might be nice to have a messaging table to then store the invites | 15:36 |
| paulr__ | so you can see who you sent/received messages from/to | 15:37 |
| paulr__ | [that oculd be a table that truncates after 30 days and shows mails or whatever] | 15:37 |
| paulr__ | in any case, as we talking around this more and more, i'm thinking that whats in the master-1.2.x branch should probably get pulled out | 15:38 |
| paulr__ | as this discussion seems to be a lot more sensible path :P | 15:38 |
| dregad | Yep | 15:38 |
| dregad | Re: the 30 day cleanup thing, not feasible without cron or something similar | 15:39 |
| paulr__ | whilst you revert the 3-4 commits on reminders | 15:39 |
| paulr__ | could you add a array_unique on the $f_to variable :P | 15:39 |
| paulr__ | as I suspect you could probably use that form to send you 50 mails from one http post request | 15:39 |
| dregad | Only if you forge the request | 15:40 |
| dregad | The gui offers a selection list | 15:40 |
| paulr__ | hmm | 15:41 |
| paulr__ | I wonder if the ability to use mantis to generate spam mails like that | 15:41 |
| paulr__ | should get a CVE thing! | 15:41 |
| paulr__ | everyone else gets CVE, I want one too | 15:41 |
| dregad | lol | 15:42 |
| * paulr__ asks person that works for norway CERT | 15:42 | |
| dregad | Just send mail to oss security | 15:42 |
| paulr__ | or just get on with life :P | 15:43 |
| dregad | That too | 15:43 |
| paulr__ | did you know you can DDOS a webserver? | 15:43 |
| paulr__ | if you send a HTTP GET / request | 15:43 |
| paulr__ | you can send 10 bytes of data | 15:43 |
| paulr__ | and get 20kb back | 15:43 |
| dregad | Speaking of which i hould probably go to bed now | 15:43 |
| paulr__ | :) | 15:43 |
| dregad | Right | 15:44 |
| paulr__ | i might look at adding invite code | 15:44 |
| paulr__ | you can then port it to 2.x | 15:44 |
| paulr__ | erm | 15:44 |
| paulr__ | you know what i mean! | 15:44 |
| dregad | But ddos is slightly more involved than a single user clicking some buttons in search.php and killing mantis | 15:44 |
| * paulr__ nosd | 15:45 | |
| paulr__ | I just think it's a hard one :) | 15:45 |
| paulr__ | personally, I prefer to fix stuff | 15:45 |
| paulr__ | then to spend time working out if a web request that generates 50 db inserts and 50 mails could warrant a security vuln | 15:46 |
| dregad | Youhave nothing better to do with your life anyway ;) | 15:46 |
| paulr__ | nod | 15:46 |
| *** Quits: dregad (~dregad@127-233.193-178.cust.bluewin.ch) (Ping timeout: 260 seconds) | 16:00 | |
| *** Joins: dregad (~dregad@127-233.193-178.cust.bluewin.ch) | 16:08 | |
| *** Quits: paulr__ (~IceChat09@cpc5-enfi19-2-0-cust776.20-2.cable.virginmedia.com) (Quit: Now if you will excuse me, I have a giant ball of oil to throw out my window) | 16:38 | |
| GitHub117 | [mantisbt] grangeway pushed 2 new commits to master-2.0.x: http://git.io/EiAcXQ | 17:24 |
| GitHub117 | mantisbt/master-2.0.x 116d9f3 Paul Richards: remove use of lang_get | 17:24 |
| GitHub117 | mantisbt/master-2.0.x fea788d Paul Richards: implement UserNotFound Exception | 17:24 |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 245 seconds) | 17:30 | |
| *** Quits: dregad (~dregad@127-233.193-178.cust.bluewin.ch) (Ping timeout: 246 seconds) | 18:21 | |
| *** Joins: dregad (~dregad@127-233.193-178.cust.bluewin.ch) | 23:09 | |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!