| *** Quits: siebrand (~beis@sm.xs4all.nl) () | 00:25 | |
| *** Quits: Shakra (d065b84e@gateway/web/freenode/ip.208.101.184.78) (Ping timeout: 252 seconds) | 01:18 | |
| *** Quits: djSupport (~djsupport@94-193-2-113.zone7.bethere.co.uk) (Read error: Connection reset by peer) | 01:27 | |
| *** Joins: djSupport (~djsupport@94-193-2-113.zone7.bethere.co.uk) | 01:34 | |
| *** Joins: Cupertino (~Cupez@unaffiliated/cupertino) | 02:33 | |
| *** Joins: Rixie (~Rixie@0x4dd7390e.adsl.cybercity.dk) | 03:01 | |
| *** Joins: giallu (~giallu@fedora/giallu) | 03:08 | |
| *** Quits: Cupertino (~Cupez@unaffiliated/cupertino) (Quit: I give up...) | 03:32 | |
| *** Joins: davidinc (d5374b7b@gateway/web/freenode/ip.213.55.75.123) | 03:43 | |
| *** Joins: kirillka (~Miranda@global-n01.vester.ru) | 05:19 | |
| *** Joins: istvanb (d917e473@gateway/web/freenode/ip.217.23.228.115) | 05:35 | |
| istvanb | hi there | 05:35 |
|---|---|---|
| istvanb | I have the following problem. Previously I had a phase "90:Rejected", but then I have realised that I can close the issue with "Closed" and "wont fix" or something like this which is equivalent to rejection. | 05:37 |
| istvanb | I have removed the 90:rejected | 05:37 |
| istvanb | but in the view issues tab "hide above" shows "@90@ or above" | 05:37 |
| istvanb | actually it is "@90@ (and above)" | 05:38 |
| istvanb | how can I fix this? | 05:38 |
| *** Quits: istvanb (d917e473@gateway/web/freenode/ip.217.23.228.115) (Quit: Page closed) | 05:51 | |
| *** Joins: istvanb (d917e473@gateway/web/freenode/ip.217.23.228.115) | 06:01 | |
| istvanb | sorry, had to disconnect | 06:01 |
| *** Joins: yisas (52960006@gateway/web/freenode/ip.82.150.0.6) | 06:01 | |
| yisas | hello | 06:01 |
| istvanb | my question is still valid, can anybody answer it? | 06:01 |
| yisas | I have a question with mantis. I have installed it on a Win2008 server + IIS 7.5 | 06:02 |
| dhx_m | istvanb: manually open up your database (after creating a backup!) and reset the statuses to "Closed" | 06:02 |
| yisas | It is a x64 arquitecture | 06:03 |
| yisas | but i keep getting "HTTP 500 - Error al llamar a LoadLibraryEx en el filtro ISAPI "C:\php\php5isapi.dll" | 06:03 |
| dhx_m | istvanb: as in, write some SQL queries to replace a status of 90 with whatever status you're using for "Closed" | 06:03 |
| yisas | any idea? please help | 06:04 |
| dhx_m | yisas: that is a problem with your configuration of IIS/PHP, not MantisBT, so you'd be better off seeking help somewhere IIS folks hang out :) | 06:04 |
| dhx_m | yisas: from the looks of things you should probably be googling "php iis isapi" | 06:05 |
| istvanb | well, the funny thing is that I have never rejected any issues, so no issues are at 90. Issues are at 70 (closed) or prior that | 06:05 |
| yisas | I already googled it | 06:05 |
| yisas | but no lack | 06:05 |
| yisas | you just are my last hope | 06:05 |
| yisas | before i start kicking the server | 06:06 |
| dhx_m | yisas: 2nd google search result: http://stackoverflow.com/questions/1235437/why-is-php5isapi-dll-missing-after-installing-php-for-windows | 06:07 |
| istvanb | kick is helping most of the times :) | 06:07 |
| istvanb | at least makes you feel better | 06:08 |
| dhx_m | istvanb: interesting... make sure you've modified your custom_strings_inc.php file too | 06:09 |
| dhx_m | and config_inc.php | 06:09 |
| istvanb | I think I know the problem | 06:09 |
| yisas | dhx, it doesn't help me much, but thanks anyway | 06:09 |
| dhx_m | there are multiple places where you will need to remove the unused status | 06:09 |
| istvanb | previously I have the rejected phase in my workflow | 06:09 |
| yisas | I think is kicking time :D | 06:09 |
| dhx_m | istvanb: use FastCGI? | 06:09 |
| istvanb | I have deleted it from the config_inc and the custom_strings_inc | 06:09 |
| istvanb | but it still in the workflow in the mantis config table | 06:10 |
| yisas | do you know if there is working x64 windows version? I just checked php.net, and there is a reference to VC9 x64 in downloads but no way to download it | 06:11 |
| dhx_m | yisas: I'm not sure, I don't use Windows :) | 06:12 |
| dhx_m | istvanb: ah, that would explain it :) | 06:12 |
| *** Quits: yisas (52960006@gateway/web/freenode/ip.82.150.0.6) (Quit: Page closed) | 06:21 | |
| istvanb | I am not sure where else it is stored | 06:23 |
| istvanb | but I still see the same | 06:23 |
| istvanb | next question. If I configure a different workflow for project2 then where the workflow is stored? | 06:33 |
| istvanb | I see only the mantis_config_table with workflow stuff | 06:33 |
| *** Joins: fanno (~Morten@90.184.93.233) | 06:56 | |
| *** Quits: dhx_m (~anonymous@c122-107-170-247.eburwd5.vic.optusnet.com.au) (Remote host closed the connection) | 07:41 | |
| *** Quits: istvanb (d917e473@gateway/web/freenode/ip.217.23.228.115) (Quit: Page closed) | 08:56 | |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 265 seconds) | 08:59 | |
| *** Joins: alexsander (~alexsande@187.113.224.10) | 09:13 | |
| *** Quits: Rixie (~Rixie@0x4dd7390e.adsl.cybercity.dk) (Quit: Rixie) | 09:20 | |
| *** Joins: hcl2_ (~hardcorel@75.41.110.112) | 09:27 | |
| *** Joins: alexsander_ (~alexsande@189.27.244.114.dynamic.adsl.gvt.net.br) | 09:31 | |
| *** Joins: daryn (~daryn@h158.249.190.173.static.ip.windstream.net) | 09:32 | |
| *** Quits: alexsander (~alexsande@187.113.224.10) (Ping timeout: 265 seconds) | 09:35 | |
| *** Joins: giallu (~giallu@fedora/giallu) | 09:38 | |
| *** alexsander_ is now known as alexsander | 09:41 | |
| *** Quits: kirillka (~Miranda@global-n01.vester.ru) (Quit: kirillka) | 09:57 | |
| *** Quits: davidinc (d5374b7b@gateway/web/freenode/ip.213.55.75.123) (Ping timeout: 252 seconds) | 10:31 | |
| *** Joins: dhx_m (~anonymous@c122-107-170-247.eburwd5.vic.optusnet.com.au) | 11:08 | |
| CIA-103 | Mantisbt: daryn * r5409ebc4e69b / (3 files in 3 dirs): Fix #10126 Add event and signal to allow plugins access to the bug change | 11:30 |
| *** Joins: paulr (~paul@cpc1-enfi9-0-0-cust389.hari.cable.virginmedia.com) | 11:45 | |
| *** Quits: alexsander (~alexsande@189.27.244.114.dynamic.adsl.gvt.net.br) (Quit: Saindo) | 12:04 | |
| *** Joins: Github (~Github@sh1-ext.rs.github.com) | 12:30 | |
| Github | mantisbt: master Daryn Warriner * 5409ebc (3 files in 3 dirs): Fix #10126 Add event and signal to allow plugins access to the bug change ... - http://bit.ly/dtNMQH | 12:30 |
| *** Parts: Github (~Github@sh1-ext.rs.github.com) | 12:30 | |
| CIA-103 | Mantisbt: daryn * r0c379c9dc6bc /core/html_api.php: Fix #11995 - Merge patch for adding id's and classes to layout elements | 12:49 |
| paulr | lo daryn | 13:10 |
| daryn | hello | 13:11 |
| paulr | we should ask these people if they mind us having copyright of patches :) | 13:11 |
| daryn | they posted it | 13:12 |
| daryn | i actually had a similar patch anyway...hence my modifications. but i figured giving credit would at least encourage involvement | 13:13 |
| paulr | did you stumble across license conversation we had in here a week back? | 13:13 |
| daryn | no | 13:14 |
| paulr | it's probably a precursor to a rare email from em | 13:14 |
| * paulr wonders if he spelt that right | 13:14 | |
| paulr | http://www.mantisforge.org/irclogs/%23mantishelp.2010-08-05.log.html | 13:15 |
| paulr | actually | 13:15 |
| paulr | http://www.mantisforge.org/irclogs/%23mantishelp.2010-08-03.log.html | 13:15 |
| paulr | deom 12:14 | 13:15 |
| paulr | erm from | 13:15 |
| daryn | how does that relate? | 13:17 |
| paulr | somewhere I drew conclusion it would be good to ask any contributor if they want to retian copyright over their patch | 13:20 |
| daryn | ew...yuck | 13:20 |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Ping timeout: 276 seconds) | 13:21 | |
| daryn | it's open source... | 13:22 |
| nuclear_eclipse | daryn: the point being that we were discussing the merits of moving to a license other than GPL | 13:24 |
| daryn | how does allowing contributers to retain copyright over patches work? Wouldn't that become a serious headache? | 13:25 |
| nuclear_eclipse | daryn: by default, they already retain it | 13:26 |
| nuclear_eclipse | the point being that if we want to changes license, we have to get agreement from all past contributers | 13:26 |
| daryn | sounds fun | 13:26 |
| nuclear_eclipse | yeah, giant PITA | 13:27 |
| CIA-103 | Mantisbt: daryn * r729d5530e87b /core/html_api.php: Fix #11995 - Add containers and ids to allow styling of various menus. | 13:29 |
| paulr | well | 13:31 |
| paulr | it shouldn't be that hard :) | 13:32 |
| paulr | I think we should license language contributors from wikitranslate thingy under same license as wikitranslate asks contributors | 13:33 |
| paulr | is that compatible with gpl? | 13:33 |
| nuclear_eclipse | paulr: I don't know | 13:35 |
| paulr | Translations by translators are licensed CC-BY 3.0, and derivative works may also be licensed under the licenses of the respective Free and Open Source projects the translations have been or will be added to. Content of user pages are considered to be "All rights reserved" by the author. All other content is licensed CC-BY 3.0 unless a different license or copyright is stated explicitly. | 13:36 |
| *** Quits: daryn (~daryn@h158.249.190.173.static.ip.windstream.net) (Quit: Ex-Chat) | 13:37 | |
| *** Quits: paulr (~paul@cpc1-enfi9-0-0-cust389.hari.cable.virginmedia.com) (Read error: No route to host) | 13:38 | |
| *** Joins: paulr (~paul@cpc1-enfi9-0-0-cust389.hari.cable.virginmedia.com) | 13:43 | |
| * paulr sighs | 13:47 | |
| *** Joins: daryn (~daryn@h158.249.190.173.static.ip.windstream.net) | 13:52 | |
| *** Joins: siebrand (~beis@sm.xs4all.nl) | 14:01 | |
| paulr | daryn: how much jquery stuff do you do btw? | 14:28 |
| daryn | quite a bit | 14:28 |
| * paulr wonders how to get started nowadays :P | 14:28 | |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 14:28 | |
| daryn | i don't know...just found things I wanted to do. | 14:29 |
| nuclear_eclipse | paulr: jquery.com | 14:29 |
| nuclear_eclipse | if you don't know how to get started from a site with that much documentation, there's no hope for you | 14:29 |
| paulr | :P | 14:29 |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Remote host closed the connection) | 14:30 | |
| paulr | right back to thinking about mantis | 14:30 |
| paulr | last friday, I slapped dhx | 14:30 |
| * paulr thinks why | 14:30 | |
| paulr | nuclear_eclipse: doyou happen to know if I can tell whether I told git in windows to fix linefeeds or not? | 14:32 |
| nuclear_eclipse | no cleu | 14:32 |
| nuclear_eclipse | I don't use windows, you seem to keep forgetting that | 14:33 |
| paulr | autocrlf = input | 14:35 |
| paulr | input? :) | 14:35 |
| paulr | in that it doesn't seem to like some of the linefeeds on libs | 14:36 |
| paulr | atm | 14:36 |
| paulr | now remind me, is it git pull or git update followed by git rebase | 14:38 |
| nuclear_eclipse | depends on what you want to do, but `git pull --rebase` is probably what you want | 14:39 |
| paulr | git fetch; git rebase origin/master | 14:39 |
| paulr | yea, it's whinging | 14:41 |
| paulr | about linefeeds ;/ | 14:41 |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 14:43 | |
| paulr | nuclear_eclipse: grr | 14:47 |
| nuclear_eclipse | paulr: stop using windows :P | 14:48 |
| paulr | need to email about licenses :) | 14:53 |
| * paulr fixes | 14:55 | |
| micahg | nuclear_eclipse: I just realized if we ever fix the debian packaging, I can set up trunk daily deb builds on Launchpad | 15:01 |
| nuclear_eclipse | micahg: nifty :P | 15:04 |
| micahg | $newmicahg = clone micahg; | 15:05 |
| micahg | $newmicahg->fixMantisDebs() | 15:05 |
| nuclear_eclipse | if only, right? !:P | 15:05 |
| micahg | nuclear_eclipse: did you see the note about a workaround for http://www.mantisbt.org/bugs/view.php?id=10873 | 15:06 |
| nuclear_eclipse | no, I've been a bit too busy lately to really keep up with any bugs on the tracker | 15:07 |
| nuclear_eclipse | but yes, I've known about that workaround for a while | 15:07 |
| micahg | ok, what should I do when I see fixes like this? | 15:07 |
| nuclear_eclipse | andy_mbt is one of my project members | 15:08 |
| micahg | nuclear_eclipse: is that not a good temporary solution? | 15:08 |
| nuclear_eclipse | and we've had that workaround in operation for as long as that bug report has been alive :P | 15:08 |
| micahg | oh, so it's my fault for not upgrading to 1.2.2? | 15:08 |
| nuclear_eclipse | no | 15:08 |
| *** Joins: Shakra (d065b84e@gateway/web/freenode/ip.208.101.184.78) | 15:09 | |
| nuclear_eclipse | I mean I've had the workaround in my local installs for a while, but I don't like wallpapering over mold, if you get what I mean :P | 15:09 |
| micahg | oh...hmmm | 15:09 |
| micahg | so the real fix is like I said to integrate the changelogs/roadmaps across projects? | 15:10 |
| nuclear_eclipse | well, the real fix is to make the project/version caching work correctly :P | 15:17 |
| nuclear_eclipse | right now, if it caches version/project data, the next time through, it sees that cache and just blindly assumes it's 100% correct and returns that list | 15:18 |
| nuclear_eclipse | so if something comes through and only grabs a subset of version data, that's all that it will ever return | 15:18 |
| * nuclear_eclipse blames dhx_m because he's not here to defend himself | 15:19 | |
| * paulr hates git | 15:22 | |
| nuclear_eclipse | http://hg-git.github.com/ | 15:23 |
| CIA-103 | Mantisbt: paul * rbec9fe83cf7d /library/ (49 files in 7 dirs): Fix linefeed warnings | 15:23 |
| paulr | i'd probably hate that too | 15:23 |
| nuclear_eclipse | why? | 15:23 |
| paulr | linefeeds can happily break anything I'm sure :) | 15:24 |
| nuclear_eclipse | so test hg-git on a copy of mantisbt.git | 15:24 |
| micahg | there's bzr-git too | 15:38 |
| micahg | foobot: bug 5668 | 16:49 |
| foobot | Bug 5668 - polzin - open - acknowledged | 16:49 |
| foobot | "versions" of parent project should be used in subprojects. - http://www.mantisbt.org/bugs/view.php?id=5668 | 16:49 |
| micahg | nuclear_eclipse: is it the same bug if a version is renamed the subproject's bugs are not pulled along or should I file a related bug | 16:50 |
| nuclear_eclipse | hmm, I thought I'd fixed that already... | 16:50 |
| micahg | nuclear_eclipse: you might have | 16:50 |
| * micahg really needs a test instance | 16:51 | |
| nuclear_eclipse | hehe | 16:51 |
| micahg | of trunk that is | 16:51 |
| nuclear_eclipse | prgmr.com | 16:51 |
| micahg | I have a server, I could run it locally, I'm jsut lazy about setting it up :) | 16:52 |
| nuclear_eclipse | k ;) | 16:52 |
| * micahg should just bite the bullet and checkout git master in my web dir | 16:52 | |
| nuclear_eclipse | I like prgmr just because it's great for dirt cheap VPS that you don't plan on using for anything with high load | 16:53 |
| *** Quits: Shakra (d065b84e@gateway/web/freenode/ip.208.101.184.78) (Quit: Page closed) | 17:17 | |
| paulr | micahg: do you need access to the code / config file | 17:21 |
| paulr | or just the UI? | 17:21 |
| micahg | paulr: UI to test, I'm setting it up now | 17:22 |
| paulr | now what was dhx's commit last weekend | 17:23 |
| *** Quits: hcl2_ (~hardcorel@75.41.110.112) (Read error: Operation timed out) | 17:24 | |
| micahg | nuclear_eclipse: it looks fixed at least in 1.3 | 17:25 |
| micahg | prgmr looks good for the price | 17:33 |
| paulr | right breaking stuff time | 17:38 |
| * paulr bounces | 17:38 | |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Quit: Leaving.) | 18:01 | |
| *** Quits: daryn (~daryn@h158.249.190.173.static.ip.windstream.net) (Quit: Ex-Chat) | 18:05 | |
| *** Joins: Github (~Github@sh1-ext.rs.github.com) | 18:30 | |
| Github | mantisbt: master Daryn Warriner * 0c379c9 (1 files in 1 dirs): Fix #11995 - Merge patch for adding id's and classes to layout elements ... | 18:30 |
| Github | mantisbt: master Daryn Warriner * 729d553 (1 files in 1 dirs): Fix #11995 - Add containers and ids to allow styling of various menus. | 18:30 |
| Github | mantisbt: master Paul * bec9fe8 (49 files in 7 dirs): Fix linefeed warnings | 18:30 |
| Github | mantisbt: master commits 5409ebc...bec9fe8 - http://bit.ly/aOFlyK | 18:30 |
| *** Parts: Github (~Github@sh1-ext.rs.github.com) | 18:30 | |
| CIA-103 | Mantisbt: paul * r6d6e255fea4b /core/obsolete.php: Update list of obsolete config variables. | 18:48 |
| *** Quits: djSupport (~djsupport@94-193-2-113.zone7.bethere.co.uk) (Remote host closed the connection) | 18:58 | |
| *** Joins: djSupport (~djsupport@94-193-2-113.zone7.bethere.co.uk) | 19:04 | |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 19:35 | |
| *** Quits: paulr (~paul@cpc1-enfi9-0-0-cust389.hari.cable.virginmedia.com) () | 19:48 | |
| *** Quits: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 20:00 | |
| *** Joins: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) | 20:00 | |
| *** Joins: HoLyVieR (~HoLyVieR@bas1-montreal48-1176174332.dsl.bell.ca) | 20:10 | |
| *** Quits: HoLyVieR (~HoLyVieR@bas1-montreal48-1176174332.dsl.bell.ca) (Quit: Leaving) | 20:18 | |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Quit: Leaving.) | 20:50 | |
| dhx_m | nuclear_eclipse: I was working on fixing project hierarchies :) | 21:38 |
| nuclear_eclipse | so stop working and get it done already :P | 21:39 |
| dhx_m | Paul and I were talking about databases the other day | 21:39 |
| nuclear_eclipse | uh oh | 21:39 |
| dhx_m | that is something I consider more urgent | 21:39 |
| dhx_m | seeing as people can't upgrade MantisBT on MSSQL, etc | 21:40 |
| dhx_m | so just to scare you... I was looking at NoSQL options :) | 21:40 |
| dhx_m | and solving the conflict problem while we're at it | 21:41 |
| nuclear_eclipse | omg | 21:43 |
| * nuclear_eclipse starts removing commit privileges | 21:43 | |
| dhx_m | haha | 21:43 |
| dhx_m | the problem with our current relational database backend is that it doesn't know what to do with merge conflicts | 21:45 |
| nuclear_eclipse | merge conflicts? wth are we merging? | 21:45 |
| dhx_m | ideally it should notify users if they're committing changes to a bug and the bug has changed since they opened the edit page | 21:45 |
| dhx_m | so they can verify what to do with the merge | 21:46 |
| nuclear_eclipse | oh, that's painful though, because it opens a can of self-replicating worms | 21:46 |
| nuclear_eclipse | basically, without going all Drupal with "everything is a node", there's not really any simple way to handle it in a way that works for everything that can be attached to an issue | 21:48 |
| nuclear_eclipse | eg, you'd have to be able to handle conflicts on custom fields, and some method of handling it for plugin data | 21:48 |
| dhx_m | well something like CouchDB keeps versions of each value stored and when it finds a conflict during replication, it picks the longest chain of revisions | 21:49 |
| dhx_m | if it stuffs up you have the full revision history to go back to | 21:49 |
| nuclear_eclipse | stop right there | 21:49 |
| nuclear_eclipse | the answer to the question is not "change backends" | 21:49 |
| dhx_m | reinvent the wheel in SQL? :p | 21:50 |
| nuclear_eclipse | no, the answer is to ignore it, or at the very least try to detect an update conflict and let the user open a new tab/page to manually sort it out | 21:50 |
| nuclear_eclipse | anything else you try to do will stuff something up in a way the user was not expecting/wanting, almost guaranteed | 21:51 |
| nuclear_eclipse | I spent two weeks of hard core thinking/planning on this a year ago | 21:51 |
| dhx_m | well the thing is, that is already the case | 21:51 |
| dhx_m | the user doesn't know if they're creating a conflict | 21:52 |
| dhx_m | ie. having a bug update window open for 2 days (in which time 10 edits are made) | 21:52 |
| nuclear_eclipse | my point is that if you try to do something smarter than interrupt a confilct and tell the user to fix it before submitting a second time, you will only make it worse | 21:52 |
| dhx_m | then after 2 days they save it, undoing those 10 edits | 21:52 |
| nuclear_eclipse | and relying on database specific rollbacks is not the answer | 21:52 |
| dhx_m | well we can/should interrupt on a conflict being detected | 21:53 |
| nuclear_eclipse | right, I've just never had the time to implement that sort of detection and interface | 21:53 |
| dhx_m | to use CouchDB as an example again, it detects conflicts for us... and it has an API for resolving conflicts manually (whichever way we want) | 21:53 |
| nuclear_eclipse | stop | 21:53 |
| nuclear_eclipse | youre not getting my point | 21:54 |
| dhx_m | as opposed to needing to do it ourselves in SQL | 21:54 |
| nuclear_eclipse | we cant implement a feature that only works on a single database that < 1% of the population uses | 21:54 |
| dhx_m | by "resolving conflicts manually" I meant that we show the user a page where they are notified a conflict exists and asks them to confirm a default action (or go back and fix it) | 21:54 |
| nuclear_eclipse | detecting the conflict outself is easy: compare last_updated timestamp | 21:55 |
| nuclear_eclipse | we don't need couchdb to tell us we're breaking things | 21:55 |
| dhx_m | we'd need granularity down to the per-field level | 21:55 |
| nuclear_eclipse | no no no | 21:55 |
| nuclear_eclipse | anything more than bug-level detection is wrong | 21:55 |
| dhx_m | mantis_bug_table could be updated from many different places (bug_update, a plugin page, etc) | 21:55 |
| nuclear_eclipse | fields aren't just distinct values | 21:55 |
| nuclear_eclipse | if you update one, a *lot* of people expect that to affect the values of other fields too | 21:56 |
| dhx_m | right | 21:56 |
| nuclear_eclipse | you *have* to defer the entire bug status back to the user | 21:56 |
| nuclear_eclipse | s/status/state/ | 21:56 |
| dhx_m | what I've been thinking is that we need another layer between the Bug class and the "users" of that data | 21:56 |
| nuclear_eclipse | sigh | 21:56 |
| dhx_m | the layer would perform the access checks amongst other checks (priority must be at least high for the severity to be above major, for instance) | 21:57 |
| nuclear_eclipse | you're over complicating things | 21:57 |
| dhx_m | at the moment we just duplicate code (badly) throughout MantisBT without a common interface for updating bugs in a consistent way | 21:57 |
| nuclear_eclipse | that sort of interstitial is 100% unrelated to handling conflicts | 21:58 |
| dhx_m | well it would be needed to resolve conflicts correctly (so the bug can't enter an invalid state where fields have conditions on their usage) | 21:58 |
| nuclear_eclipse | honestly, the best solution when a confilct is detected is to take the user back to the update form, and show both the current value (in the database) side-by-side with the values they tried to submit, and let them manually resolve the conflict and resubmit the form | 21:59 |
| nuclear_eclipse | anything other than that is only going to result in behavior that users don't want or aren't expecting | 22:00 |
| dhx_m | for instance, if status >= assigned then check if handler_id != NO_USER | 22:01 |
| nuclear_eclipse | dhx_m: that's still 100% unrelated to dealing with merge conflicts | 22:01 |
| dhx_m | well I was planning on showing things side-by-side :) | 22:02 |
| dhx_m | (in my hypothetical system) | 22:02 |
| nuclear_eclipse | dhx_m: my point is that we should only be detecting conflicts based on last_updated; anything else is going to miss something | 22:03 |
| dhx_m | true... I guess like MediaWiki? | 22:04 |
| nuclear_eclipse | esp in cases where plugins have touched last_updated because it has an attached field that changed | 22:04 |
| nuclear_eclipse | mediawiki has it easy because it's a single data field, so *any* change is by definition a conflict, and very simple to deal with | 22:05 |
| dhx_m | yep | 22:14 |
| *** Quits: fanno (~Morten@90.184.93.233) (Quit: Leaving.) | 22:27 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!