| *** Quits: kirillka (~Miranda@84-214-36-78.baltnet.ru) (Quit: kirillka) | 00:14 | |
| *** Quits: dregad (~dregad@wwwgate1.merck.de) (Ping timeout: 258 seconds) | 01:01 | |
| *** Joins: dregad (~dregad@wwwgate1.merck.de) | 01:02 | |
| *** Quits: siebrand (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) (Quit: siebrand) | 01:48 | |
| *** Joins: kirillka (~Miranda@195.242.142.17) | 02:25 | |
| *** Joins: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) | 02:46 | |
| *** Joins: giallu (~giallu@fedora/giallu) | 03:00 | |
| *** Joins: siebrand (~siebrand@213.222.6.44) | 03:21 | |
| GitHub120 | [mantisbt] dregad pushed 1 new commit to master-1.2.x: http://git.io/2fONWg | 05:21 |
|---|---|---|
| GitHub120 | [mantisbt/master-1.2.x] Fix #8504: Use is_blank() not '' to check empty path in file_add() - Damien Regad | 05:21 |
| GitHub177 | [mantisbt] dregad pushed 1 new commit to master: http://git.io/r0ocIw | 05:21 |
| GitHub177 | [mantisbt/master] Fix #8504: Use is_blank() not '' to check empty path in file_add() - Damien Regad | 05:21 |
| dhx1 | dregad: MantisBT lives! | 05:22 |
| dregad | :) | 05:22 |
| dregad | trying to keep the heart beating | 05:22 |
| * dregad has a couple (or three) more fixes pending feedback from dhx1... | 05:24 | |
| dhx1 | dregad: are they the ones on github? | 05:27 |
| dhx1 | I think one of them included changing the schema for 1.2.x? | 05:27 |
| dregad | no that was robert | 05:27 |
| dregad | let me give you the references | 05:28 |
| dregad | http://www.mantisbt.org/bugs/view.php?id=13406 | 05:28 |
| dhx1 | sorry, missed that one | 05:29 |
| dhx1 | let me check it over | 05:29 |
| dregad | http://www.mantisbt.org/bugs/view.php?id=13276 | 05:29 |
| dhx1 | ah yes, my favourite issue :) | 05:30 |
| dregad | that one's about the attachment column/indicator | 05:30 |
| dhx1 | the default values were removed from bug_report.php because they are better placed on bug_report_page.php IMO | 05:30 |
| dhx1 | but we did revert a lot of that patch later on | 05:30 |
| dregad | why is that your favorite ? | 05:31 |
| dhx1 | there was a really long bug report about custom field handling :) | 05:31 |
| dregad | so do you think I can add the default value setting back in bug_report.php ? | 05:35 |
| dhx1 | dregad: it looks like your patch at https://github.com/dregad/mantisbt/commits/fix-attach-column-13276 is OK | 05:36 |
| dregad | 'cause ATM the the custom fields are not being properly initialized | 05:36 |
| dhx1 | I don't think we have a different 'attachment' and 'attachment_count' column | 05:36 |
| dhx1 | I thought the intention may have been to allow the user to specify whether they wanted an icon or count | 05:36 |
| dregad | that's what I thought too | 05:37 |
| dhx1 | dregad: what if the default value is null, or the user has forgotten to specify a value for the compulsory field? | 05:37 |
| dhx1 | it's a problem with the custom field implementation | 05:38 |
| dhx1 | the require_ settings on custom fields vs. default values aren't clear | 05:38 |
| dhx1 | do we use a default value if that is the only thing available... when the field is required? | 05:38 |
| dregad | I see what you mean | 05:39 |
| dhx1 | or do we produce an error to inform the user that they forgot to specify the value themselves? | 05:39 |
| dhx1 | default values should only who up in text boxes/etc on the form prior to submission | 05:39 |
| dhx1 | so the user can change it | 05:39 |
| dregad | but does it make sense to have a default value for a mandatory field ? | 05:39 |
| dhx1 | _HOWEVER_ the problem was that we also have display_ fields | 05:39 |
| dhx1 | and in those cases, people were setting fields to be both required and invisible... and weren't happy with MantisBT returning an error to state that the custom field (invisible) was missing | 05:40 |
| dhx1 | dregad: these are the all the problems that my patches were attempting to clean up... although the whole custom field implementation really needs major rework to make things clearer | 05:41 |
| dregad | so basically we need to consider: is custom field required / has default value / is visible in bug report | 05:42 |
| dhx1 | yeah, but there are also thresholds for reading/writing too, I think | 05:42 |
| dregad | at custom field level ? | 05:43 |
| dhx1 | the problem is more one of the settings being too ambiguous | 05:43 |
| dhx1 | yeah | 05:43 |
| dregad | never paid attention to that. | 05:44 |
| dregad | but regardless of access, if there is a default provided it should be populated, i think | 05:44 |
| dregad | otherwise we have inconsistent behavior | 05:45 |
| dregad | the problem is maybe also one of the settings being too _ambitious_ ;-) | 05:45 |
| dhx1 | yep, so access checks will decide whether to display the field or not on the report/update/etc pages, as well as require_ and display_ settings for each custom field (!) | 05:45 |
| dregad | sounds overkill. | 05:46 |
| dhx1 | the default value should then just be copied in via HTML5's placeholder attribute (for text fields) | 05:46 |
| dhx1 | needs to be done... | 05:46 |
| dregad | i'm talking about the requirement, not the implementation | 05:46 |
| dregad | can't think of a use case for this | 05:47 |
| dhx1 | ah | 05:47 |
| dhx1 | agreed | 05:47 |
| dhx1 | basically, users want to: | 05:47 |
| dhx1 | decide who can and can't read/write to a custom field | 05:47 |
| dhx1 | decide what stage of the workflow the custom field is modified (perhaps not on report, maybe it only occurs when the status is 'assigned') | 05:47 |
| dhx1 | specifying a default value may be useful too | 05:48 |
| dregad | ok I get your point | 05:48 |
| dhx1 | but the default value would only be an aid to users, not stored in the database in place of 'null' (undefined) | 05:49 |
| dregad | this is where the pain point is actually | 05:49 |
| dhx1 | whereas what MantisBT did prior to my patch (and does right now) is store the default value in the database as soon as the bug is reported | 05:49 |
| dregad | actually right now it does not initialize it at all... | 05:49 |
| dhx1 | so you lose the ability to know whether a user has specifically added the custom field value, or whether it's just the default that every bug starts off with | 05:49 |
| dhx1 | perhaps not all of my patch was rolled back then ;) | 05:50 |
| dregad | yep :) | 05:50 |
| dregad | so in my opinion, the immediate fix should be to revert the "initialize at bug creation" behavior | 05:51 |
| dregad | and later on (1.3, next ?) to factor in your point about the default being set only after reaching a certain workflow level (i.e. when it starts to makes sense having a default set based on the field's definition) | 05:52 |
| dregad | what do you think ? | 05:52 |
| dhx1 | I'd still disagree on the basis that we should check for a null value returned from the database, and display the default value _if we really need to_ | 05:54 |
| dregad | to cover for the case of a mandatory field ? | 05:57 |
| dhx1 | 11684 is the other fun read | 05:58 |
| dhx1 | that issue takes a different approach: that list, enum, etc fields can not hold a null value | 05:58 |
| dregad | Ah yes, 11684 - that was a good one | 05:59 |
| dhx1 | the basis of that argument is mathematical (set theory) | 05:59 |
| dregad | the basis of the counter-argument is real-life ;-) | 06:00 |
| dhx1 | agreed | 06:01 |
| dhx1 | in which the argument is that some users may want fields that never allow a null value (undefined) | 06:01 |
| dregad | I ended up adding an "Undefined/NA" entry in the sets where I was impacted by this | 06:01 |
| dhx1 | and some users want fields that allow null values in addition to other specified values | 06:02 |
| dhx1 | it's more of a logic/reasoning/philosophical thing | 06:02 |
| dhx1 | once a user selects "null" as the value of a custom field, can it ever be unselected? :P | 06:02 |
| dregad | no, but that's the UI preventing it | 06:03 |
| dhx1 | it depends on how we treat "null" | 06:03 |
| dregad | that too | 06:03 |
| dhx1 | right, the UI controls don't let us easily unselect a value back to 'null'... but even if they did, it's not "undefined" in the original sense of the term | 06:04 |
| dhx1 | it has now been defined to be "undefined" :P | 06:04 |
| dregad | LOL | 06:04 |
| dregad | you do have a scientific background, don't you | 06:05 |
| dhx1 | we can probably accept the loss of the original meaning of "undefined" | 06:05 |
| dhx1 | haha yeah | 06:05 |
| dhx1 | but in some cases, maybe users want to distinguish between custom field values that have received human consideration, and those that have not ever been addressed | 06:06 |
| dhx1 | was it consciously set to undefined, or has the question never been considered? | 06:06 |
| dregad | possibly, but in that case they should not define a default value | 06:06 |
| dhx1 | a default value is still useful though, to aid users when they do make the concious decision to update the custom field ;) | 06:07 |
| dregad | OK, so it's now an argument of "recommended" vs "pre-set" value (default is not precise enough) | 06:08 |
| dregad | in my book and all apps and DB values I've worked with, default == pre-set | 06:09 |
| dhx1 | this problem could probably be solved by allowing custom field values to be redefined based on the status of an issue | 06:09 |
| dhx1 | so for a 'new' issue, the custom field value must be undefined | 06:09 |
| dhx1 | for an 'acknowledged' issue, the custom field value can be undefined, 'a' or 'b' | 06:10 |
| dhx1 | for an 'assigned' issue, the custom field value must be 'a', 'b' or 'c' | 06:10 |
| dhx1 | etc | 06:10 |
| dregad | that's another can of worms ;-) | 06:10 |
| dregad | but it makes sense | 06:10 |
| dregad | although at the moment, the restriction is not based on workflow (status), but on the screen (report, update, resolve, close) | 06:11 |
| dhx1 | I still don't like 'undefined' for many fields because there is no way in the UI to choose this state | 06:11 |
| dhx1 | yeah | 06:11 |
| dregad | Without changing this restriction, the most correct behavior would be to only initialize the custom field to the default value, at the "earliest" stage where it becomes visible | 06:12 |
| dregad | before that, it is "undefined" in the mathematical sense of the word | 06:13 |
| dhx1 | it'd have to be done on 'required' | 06:13 |
| dhx1 | _or_ 'visible' (I think) | 06:13 |
| dregad | you're right | 06:14 |
| dhx1 | I'm not too fussed what we do with 1.2.x/1.3.x at the moment | 06:14 |
| dhx1 | unless it breaks the way it currently works | 06:14 |
| dregad | So I'd propose the following | 06:14 |
| dregad | 1. set default at bug create for now (i.e. quick and easy fix 13406) | 06:15 |
| dregad | 2. create a new issue to track a better, more comprehensive fix as just described | 06:15 |
| dhx1 | just (1) :) | 06:16 |
| dhx1 | _however_ there is a reason 11684 was needed | 06:18 |
| dhx1 | how do we detect the difference between a checkbox field that has no items selected (null set) and a failure for the user to consciously consider setting the field to a null set? | 06:19 |
| dhx1 | it gets fun :) | 06:19 |
| dhx1 | https://secure.wikimedia.org/wikipedia/en/wiki/Empty_set#Questioned_existence | 06:21 |
| dregad | need 2 values (NULL = undefined and EMPTY) | 06:21 |
| dregad | but question remains, do we really need it in the real world | 06:21 |
| dhx1 | we wouldn't... if these restrictions were enforced directly in the database schema with CHECK constraints | 06:22 |
| dhx1 | (probably not, anyway) | 06:22 |
| dhx1 | however we'd need to address the prospect of other code/plugins/import features/whatever writing to the same database and not having any knowledge of certain fields existing | 06:23 |
| dhx1 | how do you import issues from a bug tracker that doesn't have any custom fields, to a bug tracker that expects certain custom fields to be in place? | 06:23 |
| * dregad has a headache now | 06:24 | |
| dhx1 | the answer would be via a "type conversion" (either automatically setting default values where missing, or asking the user to manually make corrections for each imported issue) | 06:25 |
| dhx1 | haha yeah | 06:25 |
| dregad | to answer your last questions - records should be rejected and the import set updated by user to provide values | 06:25 |
| dregad | ok you typed faster than me | 06:25 |
| dhx1 | that's one valid way of looking at it :) | 06:25 |
| dregad | valid, more easy and guaranteed to be consistent | 06:26 |
| dregad | that's how I handled external data interfaces here | 06:26 |
| dhx1 | it's the kind of thing where we'd ask users to transform (via XSLT) their XML exported issues, adding the custom field values, prior to importing to the new bug tracker | 06:26 |
| dregad | exactly | 06:26 |
| dhx1 | (XML example) | 06:26 |
| dregad | as long as the import mechanism as the ability to flag rejected records and provide some details for why they were rekected | 06:27 |
| dregad | *has the hability | 06:27 |
| dregad | *ability | 06:27 |
| dhx1 | yeah we can do that easily | 06:28 |
| * dregad blames fat fingers | 06:28 | |
| dhx1 | especially with the new exception handling in the 'next' branch | 06:28 |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 240 seconds) | 06:28 | |
| dregad | speaking of which - have not seen many commits there lately... been busy ? | 06:29 |
| dhx1 | yeah | 06:31 |
| dhx1 | I was actually doing some work locally on MantisBT | 06:31 |
| dhx1 | trying out some new approaches to templating/redoing the UI | 06:31 |
| dregad | did you ever reconcile your work with Paul's ? | 06:32 |
| dhx1 | his branch is on a separate tangent ;) | 06:32 |
| dhx1 | I've merged a fair bit of his branch into 'next' | 06:32 |
| dregad | so we have next-dhx1, next-paul, 1.3.x........ | 06:33 |
| dhx1 | but other parts are duplicates/etc | 06:33 |
| dhx1 | that's distributed development for you ;) | 06:33 |
| dhx1 | may the best branch win haha | 06:33 |
| dregad | i.e. the 1st one to push to master ? | 06:33 |
| dhx1 | nah, to get wide acceptance | 06:34 |
| dhx1 | for a project as small as MantisBT, that'd probably be a mailing list thread | 06:34 |
| dhx1 | (that will occur anyway for any significant merge request) | 06:34 |
| dregad | it really felt like ego crashes few weeks ago | 06:35 |
| dregad | *clashes | 06:35 |
| dhx1 | we both tried different ways of doing the same thing | 06:35 |
| dhx1 | I think the only _real_ difference at the moment is with exception handling | 06:36 |
| dhx1 | Paul's branch allows you to throw exceptions that don't exist | 06:36 |
| dhx1 | whereas my 'next' branch has concrete exception classes | 06:36 |
| dhx1 | you can't catch exceptions that aren't defined (you'd have to catch the generic exception base class and then manually check what it is) | 06:36 |
| dhx1 | but the downside of defining all exception classes is the amount of work that involves (which I've already done btw) | 06:37 |
| dregad | I don't have enough spare time to invest into this (next) unfortunately | 06:37 |
| dhx1 | understood... it may go nowhere, we'll see | 06:37 |
| dregad | Anyway Paul sounded a bit miffed, by this parallel work as well as John's kicking his IRC bot and then setting up another archive on mantisbt.org | 06:38 |
| dhx1 | it's a lot of work and it's fairly ambitious because much of what we were trying to do hasn't been done by web applications many times before | 06:38 |
| dhx1 | if you've cracked open the source code to other web apps, you'll see what I mean... it makes MantisBT source code look like a shining example of brilliance :) | 06:39 |
| dregad | amen | 06:39 |
| dhx1 | the IRC bot issue was just because of #mantis-help redirecting to #mantisbt-help | 06:40 |
| dregad | not only | 06:40 |
| dhx1 | and the bot hadn't been updated for that change, so it kept quiting/rejoining | 06:40 |
| dregad | Paul24 "what I dont expect is someone to 'replace' something i've been running for 3 years without saying anything" | 06:43 |
| dregad | in http://www.mantisbt.org/irclogs/mantisbt-help/mantisbt-help_2011-09-27.log.html | 06:43 |
| dregad | anyway. | 06:43 |
| dregad | Lunchtime | 06:43 |
| dregad | thanks for your feedback | 06:44 |
| dhx1 | yeah I didn't follow that much ;) | 06:44 |
| dhx1 | ttyl :) | 06:44 |
| *** Joins: giallu (~giallu@fedora/giallu) | 07:06 | |
| GitHub29 | [mantisbt] dregad pushed 1 new commit to master-1.2.x: http://git.io/hcMLsg | 07:17 |
| GitHub29 | [mantisbt/master-1.2.x] Init custom fields default value when reporting bug - Damien Regad | 07:17 |
| GitHub1 | [mantisbt] dregad pushed 1 new commit to master: http://git.io/HsR7gA | 07:17 |
| GitHub1 | [mantisbt/master] Init custom fields default value when reporting bug - Damien Regad | 07:17 |
| dregad | @jreese, it seems my last commits were not picked up by source control plugin - changesets not available in tracker http://www.mantisbt.org/bugs/plugin.php?page=Source/list&id=7 | 07:20 |
| *** Quits: siebrand (~siebrand@213.222.6.44) (Quit: siebrand) | 08:12 | |
| dregad | jreese - nevermind they just took their time to arrive | 08:16 |
| *** Joins: extreme001 (~jensen@dyndsl-091-096-044-197.ewe-ip-backbone.de) | 08:47 | |
| extreme001 | hi | 08:47 |
| dhx1 | extreme001: hi | 08:47 |
| extreme001 | i need help. Can someone tell me which database-version of mantisbt is the right for mantis 1.28 ? | 08:48 |
| dhx1 | #mantisbt-help for these sorts of questions (usually) | 08:48 |
| dhx1 | I don't have 1.2.8 installed so I can't check the version at the moment | 08:49 |
| extreme001 | ok | 08:49 |
| extreme001 | thnx | 08:49 |
| dhx1 | but #mantisbt-help is the best place to ask (more users, this channel is just developer talk) | 08:49 |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 244 seconds) | 09:08 | |
| *** Quits: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) (Remote host closed the connection) | 09:33 | |
| *** Joins: giallu (~giallu@fedora/giallu) | 09:39 | |
| jreese | dregad: I did a manual import, I'm not sure why the remote checkins aren't working atm | 09:42 |
| jreese | just got too busy to mention it | 09:42 |
| jreese | I'll have to debug the issue from the server side, most likely has to do with either authenticating the remote checkin or decoding the github payload, esp since they recently added new service hook abilities | 09:43 |
| dregad | jreese: thx for feedback - so you'll fix it before or after moving to SF ? ;-) | 09:46 |
| *** Quits: dregad (~dregad@wwwgate1.merck.de) (Quit: Ex-Chat) | 09:47 | |
| *** Joins: dregad (~dregad@wwwgate1.merck.de) | 09:47 | |
| *** Quits: dregad (~dregad@wwwgate1.merck.de) (Client Quit) | 09:47 | |
| *** Joins: dregad (~dregad@wwwgate1.merck.de) | 09:47 | |
| jreese | dregad: having fun? :P | 09:48 |
| dregad | trying to | 09:48 |
| jreese | and it depends on how much time I get | 09:48 |
| dregad | are you packing yet ? | 09:49 |
| jreese | I really need to add some sort of official logging mechanism to source integration too | 09:49 |
| jreese | no, EA is paying for professional movers, so we don't have to pack anything ourselves | 09:49 |
| jreese | they contracted a relocation company for us, and they're taking care of almost everything for us, it's actually quite nice | 09:51 |
| dregad | best kind of move ! | 09:52 |
| *** Quits: dregad (~dregad@wwwgate1.merck.de) (Client Quit) | 09:52 | |
| *** Joins: dregad (~dregad@wwwgate1.merck.de) | 09:53 | |
| jreese | yeah, it would have been extremely stressful otherwise, but right now the biggest issue is finishing all the renovations we started on our condo so we can sell it | 09:53 |
| *** Quits: kirillka (~Miranda@195.242.142.17) (Quit: kirillka) | 10:00 | |
| *** Joins: kirillka (~Miranda@221-79-52-95.baltnet.ru) | 10:19 | |
| *** Quits: kirillka (~Miranda@221-79-52-95.baltnet.ru) (Quit: kirillka) | 10:55 | |
| *** Quits: extreme001 (~jensen@dyndsl-091-096-044-197.ewe-ip-backbone.de) (Quit: Nettalk6 - www.ntalk.de) | 11:22 | |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 244 seconds) | 11:40 | |
| *** Joins: siebrand (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) | 17:26 | |
| *** Quits: siebrand (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) (Read error: Connection reset by peer) | 19:06 | |
| *** Joins: siebrand_ (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) | 19:06 | |
| *** Joins: siebrand (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) | 19:07 | |
| *** Quits: siebrand_ (~siebrand@5353A6DC.cm-6-4c.dynamic.ziggo.nl) (Read error: Connection reset by peer) | 19:07 | |
| *** Quits: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 20:00 | |
| *** Joins: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) | 20:00 | |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!