| ../irclogs/#mantishelp.2009-12-16.log | ||
| --- scribe started --- | 00:00 | |
| CIA-27 | Mantisbt: vboctor * r77a0fb65a207 /core/user_pref_api.php: Fixes #11046: notification emails send to an unassigned user. | 09:29 |
|---|---|---|
| CIA-27 | Mantisbt: vboctor master-1.2.x * r6ff6210c3e88 /core/user_pref_api.php: Fixes #11046: notification emails send to an unassigned user. | 09:29 |
| killefiz | giallu: what do you think about pushing a git-snapshot of 1.2.x to rawhide? | 10:36 |
| giallu | killefiz, I considered doing that about 6 month ago... I'm just glad I waited :) | 10:39 |
| giallu | now it seems we're _really_ near a release, so it could make sense | 10:40 |
| killefiz | i'm using 1.2 in production for months now | 10:53 |
| dhx_m | I just came across the best thing I've seen in HTML forms ever | 11:00 |
| dhx_m | HTML5 has a text field that has a draggable corner, allowing users to resize the field to meet their needs as they type | 11:01 |
| dhx_m | and the new <datalist> tag also seems very useful | 11:05 |
| dhx_m | essentially you can have autocomplete in text fields where values are taken from the datalist | 11:05 |
| dhx_m | that might be handy for our project or user selector where we can have 100's of projects and 1000's of users to select from | 11:06 |
| kirillka | nuclear_eclipse: around? | 13:15 |
| nuclear_eclipse | howdy | 13:31 |
| paul__ | . | 13:59 |
| paul__ | wuts rawhide | 13:59 |
| nuclear_eclipse | fedora's unstable/testing | 14:00 |
| paul__ | have you seen the MS docs | 14:00 |
| paul__ | on php stuff | 14:00 |
| paul__ | erm | 14:00 |
| nuclear_eclipse | no | 14:00 |
| paul__ | for their application deployment thingie | 14:00 |
| paul__ | OMG | 14:02 |
| * paul__ knows what he's doing tonight | 14:03 | |
| kirillka | nuclear_eclipse: hi | 14:57 |
| kirillka | John, did you know git web interface for closed project? | 14:57 |
| kirillka | such github with closed projects | 14:58 |
| kirillka | nuclear_eclipse: John? | 15:17 |
| CIA-27 | Mantisbt: vboctor * r5955e8b9aa3f /bug_change_status_page.php: Fixes #10023: duplicate_id maxlength is hardcoded in bug_change_status_page.php. | 15:20 |
| CIA-27 | Mantisbt: vboctor master-1.2.x * ref5688b47591 /bug_change_status_page.php: Fixes #10023: duplicate_id maxlength is hardcoded in bug_change_status_page.php. | 15:21 |
| paul__ | dhx_m: | 15:23 |
| paul__ | did you fix the url issuesxss? | 15:23 |
| paul__ | a | 16:08 |
| nuclear_eclipse | omg, these splits are driving me insane | 16:15 |
| nuclear_eclipse | I've never seen freenode so split-happy before | 16:15 |
| paul__ | nuclear_eclipse: :) | 18:13 |
| nuclear_eclipse | hi paul__ | 18:31 |
| * paul__ is having fun :) | 18:32 | |
| paul__ | or well | 18:32 |
| paul__ | will be | 18:32 |
| ezraw | anyone know how I can get my custom fields into the csv export? | 18:39 |
| kirillka | nuclear_eclipse: did you know git web interface for closed project? Such github with closed projects. | 19:47 |
| Dgtlrift_at_work | Are there any plugins to render Gantt charts in mantis? | 20:16 |
| giallu | Dgtlrift_at_work, good question... I never come across one | 20:17 |
| Dgtlrift_at_work | Can you make a guess at the time to implement such a plugin? Is there another plugin that does graphs that can be borrowed like one that dies a burn down? | 20:25 |
| qwebirc611429 | This is much better... Dod you get my last question? | 20:27 |
| * giallu still pondering | 20:28 | |
| giallu | I'm not sure we wave any plugin with semi-complex graphs | 20:29 |
| giallu | we _have_ | 20:29 |
| qwebirc611429 | unfortunate | 20:29 |
| qwebirc611429 | It would seem for the gantt graph we /mosty/ everything - relationship tracking, issue complexity (effort in terms of time,) and project association... | 20:31 |
| qwebirc611429 | .../mostly/ have evverything... | 20:31 |
| qwebirc611429 | ... what is lacking would be interproject resource tracking - ei joe is 100% on project "A" and has the expertiese associated with Ticket X, Y, and Z. | 20:33 |
| qwebirc611429 | BTW: this is dgtlrift_at_work - I just couldn't handle the IRC client through the web page on my phone - so now I'm at a desktop. | 20:34 |
| qwebirc611429 | We also have the graphing code for the roadmap that could be recycled. | 20:36 |
| qwebirc611429 | giallu - do you agree? | 20:39 |
| giallu | dgtlrift_at_work, sure it could | 20:39 |
| dgtlrift_at_work | Would I be better off documenting it in a ticket to get some feedback? | 20:42 |
| dgtlrift_at_work | got to go - tnx for the advice | 20:45 |
| paul__ | whos around? | 21:38 |
| nuclear_eclipse | me | 21:38 |
| paul__ | hmm | 21:38 |
| paul__ | you'll do | 21:38 |
| paul__ | atm we can customise fields on bug report page right? | 21:39 |
| nuclear_eclipse | yep | 21:39 |
| paul__ | but not order them? | 21:39 |
| nuclear_eclipse | dunno | 21:39 |
| paul__ | or well, lay them out? | 21:39 |
| nuclear_eclipse | but that reminds me, we wanted to change all those constants to normal strings | 21:39 |
| paul__ | if we were to lay them out | 21:39 |
| paul__ | nod | 21:40 |
| paul__ | almost done that :P | 21:40 |
| paul__ | if we were to lay them out | 21:40 |
| paul__ | we'd need to store array( array(id, status), array( os,os_build,blank,eta) type structure? | 21:40 |
| paul__ | serialise that into config ? | 21:40 |
| nuclear_eclipse | that sounds insane :P | 21:44 |
| paul__ | well table? | 21:55 |
| paul__ | or what :P | 21:55 |
| paul__ | you have 24 hours to come up with a good way to store rows :P | 21:56 |
| nuclear_eclipse | do we really need to worry about that right now? | 21:56 |
| paul__ | yep :P | 21:57 |
| paul__ | you know it's xmas? | 21:57 |
| nuclear_eclipse | can we worry about cleaning up 1.2 first? | 21:57 |
| paul__ | I kinda am :P | 21:58 |
| paul__ | i'm going through my list :) | 21:59 |
| * paul__ wonders if dhx_m has a view | 22:10 | |
| paul__ | wow | 22:44 |
| paul__ | wtf is helper_get_columsn_to_view | 22:44 |
| nuclear_eclipse | ugh | 22:44 |
| nuclear_eclipse | I don't even feel like trying to explain it | 22:45 |
| paul__ | ? :) | 22:45 |
| paul__ | well | 22:45 |
| paul__ | it's a fairly random function | 22:45 |
| nuclear_eclipse | it's one of those things I have to re-explore every time I come across it because it's so weird and indirect | 22:45 |
| paul__ | I've just coded a columns_get_default() function to use in config_Set | 22:46 |
| paul__ | and now found helper_get_columns_to_view | 22:46 |
| paul__ | which does something similar but not the same! | 22:46 |
| paul__ | (columns_get_default is to replace the hardcoded columns in config_default's as the hard coded columns don't work properly as you can turn features on/off so need to be dynamic | 22:47 |
| paul__ | now I need to work out if i've | 22:47 |
| paul__ | a) just wasted my time | 22:47 |
| paul__ | b) if I can just deleted the helper_* function | 22:47 |
| nuclear_eclipse | I'm pretty sure that helper_ takes care of all that | 22:47 |
| paul__ | c) if we need both :/ | 22:47 |
| nuclear_eclipse | either way, don't break the way that plugin columns works | 22:48 |
| paul__ | i'm not :) | 22:48 |
| paul__ | I'm purely making default config_get take a default value of not '' | 22:48 |
| paul__ | or well | 22:48 |
| paul__ | removing $g_csv_columns from config defaults | 22:48 |
| paul__ | and replace with a default value in config_get of column_get_default('csv') | 22:49 |
| paul__ | such that the default values are appropriate for fields that are actually enabled | 22:49 |
| paul__ | (such that we dont store columns that are default and unchanged in db) | 22:49 |
| dhx_m | hi | 22:51 |
| paul__ | hi | 22:51 |
| mourisj | join #mirth | 22:52 |
| nuclear_eclipse | dinner time, might be on phone | 22:52 |
| nuclear_eclipse | cheers | 22:52 |
| paul__ | mourisj: no | 22:52 |
| mourisj | sorry | 22:52 |
| paul__ | :P | 22:53 |
| mourisj | btw, they are currently mirthcorp.com | 22:54 |
| paul__ | dhx_m: confirm: duplicate_id = dead? | 23:06 |
| dhx_m | paul__: I'm not too familiar with "duplicate_id"...? | 23:07 |
| paul__ | prior to relationships :P | 23:07 |
| paul__ | can you review a patch? :P | 23:10 |
| paul__ | also any thoughts on layout comment I had with john? | 23:11 |
| dhx_m | well duplicate_id is still in the schema | 23:11 |
| dhx_m | whatever it does | 23:11 |
| dhx_m | paul__: I'm not 100% sure on the best way to approach ordering of fields | 23:12 |
| dhx_m | paul__: it really should be something the user can customise in a UI (when they select what fields to show) | 23:13 |
| dhx_m | paul__: however when we move to templating, it's going to get ugly when we have to change the order of templates | 23:13 |
| * paul__ is more keen to allow users to customise fields in UI | 23:14 | |
| paul__ | kinda interested in ways to store data | 23:15 |
| * paul__ goes to look at what deboutv did | 23:15 | |
| paul__ | dhx_m: so options | 23:24 |
| paul__ | a) store sql tables | 23:24 |
| paul__ | b) store a config entry (Array( '0_0'=>'reporter', 0_1=>foo etc | 23:25 |
| paul__ | or multideminsional array | 23:25 |
| dhx_m | well the problem I see is that some layout templates may have 2/3 columns | 23:29 |
| dhx_m | others may have something completely different | 23:29 |
| dhx_m | so it becomes very hard to order stuff if we use that approach | 23:30 |
| dhx_m | then again, we really need a generic way for printing fields | 23:30 |
| dhx_m | as the user may have 10 custom fields | 23:30 |
| paul__ | I need a way to allow a user to modify the order of fields on http://www.mantisbt.org/bugs/view.php?id=4350 | 23:30 |
| paul__ | atm, you can turn some of them off | 23:31 |
| paul__ | but not hide all | 23:31 |
| paul__ | and not fix layout if you hide some | 23:31 |
| paul__ | what deboutv did with my view was | 23:31 |
| dhx_m | I'd say it should be a 2D array from most important to least important fields | 23:31 |
| paul__ | set up some massive table | 23:32 |
| paul__ | with fields 0_0,0_1,0_2 etc | 23:32 |
| paul__ | then stored either blank, fieldname, or mergeleft/right | 23:32 |
| paul__ | i'm not sure about merge left/right as that's a bit silly | 23:32 |
| paul__ | but | 23:32 |
| paul__ | fieldname, width | 23:32 |
| paul__ | and row | 23:32 |
| dhx_m | interesting | 23:32 |
| dhx_m | now you mention it | 23:33 |
| dhx_m | it should probably be a multi-dimensional array | 23:33 |
| dhx_m | where you can group fields together | 23:33 |
| dhx_m | it should be possible to design quick algorithms to work out spacing as appropriate | 23:33 |
| paul__ | http://www.mantisbt.org/bugs/view.php?id=4350 | 23:34 |
| paul__ | why does top row show | 23:34 |
| paul__ | ID | 23:34 |
| paul__ | 0000 | 23:34 |
| paul__ | whereas everything else show | 23:34 |
| paul__ | Reporter: foo | 23:34 |
| dhx_m | I agree, that sucks :p | 23:35 |
| paul__ | you could represent that table atm by store an array of rows | 23:35 |
| dhx_m | IMO it should be one or the other | 23:35 |
| paul__ | where a row has a type (aka top/bottom, left/right) | 23:36 |
| paul__ | and an array of fields | 23:36 |
| paul__ | where a field has a variable name and a width | 23:36 |
| dhx_m | I was actually thinking it should be configurable on a per-project basis (and probably per-user or per-group basis too) | 23:36 |
| paul__ | in all honesty, I think mantis is something that needs to be skinnable, have a bit of a facelift into ajax world | 23:37 |
| paul__ | and after that templates comes down to something to make our lives easier, not endusers | 23:38 |
| dhx_m | the main reason for templates IMO is to allow for different layouts (mobile, wide screen, simplified, etc) | 23:38 |
| paul__ | right | 23:39 |
| paul__ | 23:34 < dhx_m> it should probably be a multi-dimensional array | 23:40 |
| paul__ | 23:34 < dhx_m> where you can group fields together | 23:40 |
| paul__ | 23:35 < dhx_m> it should be possible to design quick algorithms to work out spacing as appropriate | 23:40 |
| paul__ | so erm | 23:40 |
| paul__ | any thoughts of structure? | 23:40 |
| dhx_m | we should be able to get spacing information from the fields themselves (maximum length, etc) | 23:41 |
| dhx_m | what we're really interested in is grouping of similar fields | 23:42 |
| dhx_m | as well as the order to display them | 23:42 |
| dhx_m | so the array structure would probably look like: | 23:42 |
| paul__ | well grouping of similar user could do | 23:42 |
| paul__ | if you allowed them to place them | 23:42 |
| dhx_m | array[] = array('os', 'os_version', 'php_version', 'whatever'); | 23:43 |
| dhx_m | array[] = 'custom_field_something'; | 23:43 |
| dhx_m | array[] = array('target_version', 'due_date', 'etc'); | 23:44 |
| dhx_m | so with the current three column layout | 23:44 |
| dhx_m | It'd show the os, os_version, etc as 2 rows of 2 columns | 23:44 |
| dhx_m | the custom field thingy as it's own line (perhaps)? | 23:45 |
| dhx_m | and the target_version, etc as 1 row of 3 columns | 23:45 |
| dhx_m | of course, depending on field lengths... the 'etc' field may be a long text field that requires the entire page width | 23:45 |
| paul__ | I partly wonder if one just does | 23:47 |
| paul__ | (array( array('os',1') array('target_version',2)) | 23:47 |
| dhx_m | aren't those array orders implicit (keys by default are addressed numerically)? | 23:48 |
| paul__ | i mean width | 23:48 |
| dhx_m | width doesn't make sense for every layout | 23:48 |
| dhx_m | ie. single column view of fields | 23:49 |
| paul__ | well, with a single column view, you'd have to put each field on it's own row | 23:50 |
| dhx_m | yep, but you can still group them vertically using HTML fieldsets | 23:50 |
| dhx_m | for example | 23:50 |
| paul__ | ahhhmm | 23:51 |
| paul__ | I see what you mean | 23:51 |
| dhx_m | I just think the "layout engine" should be responsible for working out widths, spacing, etc | 23:52 |
| dhx_m | because they're not the same on every layout | 23:52 |
| dhx_m | and it is something that could be determined quite easily by some quick PHP code | 23:52 |
| paul__ | so your thinking an array of sets of fields | 23:53 |
| dhx_m | yep | 23:53 |
| paul__ | which could be rows or otherwise | 23:53 |
| dhx_m | yeah | 23:53 |
| * paul__ shall have a play | 23:53 | |
| dhx_m | essentially, it's a group of fields that are similar in some way | 23:53 |
| dhx_m | and because we don't know what fields exist at design time (users may add their own) | 23:54 |
| dhx_m | we really need to let the users have control over how they're grouped together and how they're ordered | 23:54 |
| paul__ | well, that's essentially what defining the table layout would do | 23:55 |
| dhx_m | but it assumes there is a table :) | 23:56 |
| dhx_m | grouping also could have other uses | 23:56 |
| dhx_m | unrelated to generating views | 23:56 |
| paul__ | tbh once you go down the route of it might be a table, it might be css it might be div | 23:57 |
| paul__ | gl with plugins ;) | 23:57 |
| dhx_m | my point is that plugins would specify a new type of field | 23:58 |
| paul__ | who mentioned field :) | 23:58 |
| dhx_m | aka 'column' in our current implementation | 23:58 |
| * nuclear_eclipse shudders at the content of the backlog... | 23:59 | |
| dhx_m | nuclear_eclipse: how else do we handle templating *and* custom fields at the same time? | 23:59 |
| nuclear_eclipse | umm, we don't? :P | 23:59 |
Generated by irclog2html.py