| *** Joins: dregad (~dregad@155.250.128.35) | 00:05 | |
| *** Quits: dregad (~dregad@155.250.128.35) (Quit: Ex-Chat) | 01:13 | |
| *** Joins: dregad (~dregad@155.250.128.35) | 01:13 | |
| *** Quits: dregad (~dregad@155.250.128.35) (Client Quit) | 01:13 | |
| *** Joins: dregad (~dregad@155.250.128.35) | 01:13 | |
| *** Joins: Paul_46 (~IceChat09@cpc1-enfi15-2-0-cust580.hari.cable.virginmedia.com) | 03:38 | |
| Paul_46 | dregad: mo? | 03:46 |
|---|---|---|
| Paul_46 | or jreese even | 03:46 |
| dregad | <Paul_46> ? | 05:09 |
| Paul_46 | lo | 05:10 |
| Paul_46 | events | 05:10 |
| Paul_46 | any idea why john might have put the signals in random files e.g. bug_update.php and not in bug api's update function | 05:11 |
| dregad | not really no | 05:14 |
| dregad | maybe because the event handler may interact with the GUI | 05:14 |
| Paul_46 | that strikes me as something you should be able to detect | 05:15 |
| Paul_46 | i.e. if you delete a bug, which deletes bugnotes for instance | 05:15 |
| Paul_46 | that should fire bugnote delete event for each bugnote then a bug delete event | 05:15 |
| Paul_46 | and wow | 05:19 |
| Paul_46 | gonna need to think about this | 05:19 |
| dregad | it would make more sense to have them in the api I guess - guarantees integrity and consistent calling of events | 05:35 |
| Paul_46 | [PATCH 264/350] Add 'Close' button for bugs | 06:17 |
| Paul_46 | dregad: from memory we used to have a close button | 06:17 |
| Paul_46 | but then it got removed | 06:17 |
| GitHub37 | [mantisbt] siebrand pushed 1 new commit to master-1.2.x: http://git.io/NGM2YA | 07:03 |
| GitHub37 | [mantisbt/master-1.2.x] Localisation updates from http://translatewiki.net. - Siebrand Mazeland | 07:03 |
| *** Quits: kirillka (~Miranda@195.242.142.17) (Quit: kirillka) | 07:06 | |
| dregad | why was it removed ? it's a necessary feature when you allow reporters to close | 08:43 |
| dregad | iirc, using the 'change status' list + button instead, caused issues (security due to workflow bypass) | 08:45 |
| dregad | see http://www.mantisbt.org/bugs/view.php?id=14156 | 08:45 |
| Paul_46 | right - bbiab | 09:05 |
| *** Quits: giallu (~giallu@fedora/giallu) (Remote host closed the connection) | 09:41 | |
| *** Quits: dregad (~dregad@155.250.128.35) (Quit: Ex-Chat) | 10:02 | |
| jreese | Paul_46: I agree with you that a lot of the events *should* be part of the API, but the problem is, as dregad guessed, because most of the use cases that I was dealing with were explicitly surrounding improvements or additions to the user interface, and calling the API's from non-UI contexts would either cause errors when triggering the events, or would greatly complicate the way in which plugins would need to use those events | 10:03 |
| jreese | ideally, I think two sets of events are really needed: one set of events embedded into the API to enable extending pure business logic, and a second "outer" set of events that are specific to the needs of the UI | 10:03 |
| Paul_46 | atm, i'm trying to get them to be part of the API | 10:55 |
| Paul_46 | for things like 'bugupdate/delete, notes etc | 10:55 |
| Paul_46 | a simple "plugin" I can think someone might like to have is to get a notification when a bugnote is deleted | 10:55 |
| Paul_46 | and atm, the bugnote delete hook only triggers in certain places | 10:55 |
| Paul_46 | atm, if you add a bugnote via the legacy soap api it does't get logged - so kinda 'breaks' plugins anyway | 10:57 |
| Paul_46 | at the same time, i've been trying to move some of the logic for various things into the core api, so that it's easier to add a bug/note via a future webservice api or mobile interface | 10:58 |
| Paul_46 | however, it's a big experiment atm | 10:58 |
| jreese | well, depending on the plugin, letting the SOAP API trigger the event can "break" things as well; that's what I was trying to get at above | 10:58 |
| Paul_46 | yea | 10:58 |
| Paul_46 | however, i'd probably argue that the plugin should handle that | 10:59 |
| jreese | yes and no | 10:59 |
| Paul_46 | it could be a mobile client, a web browser or a xmlrpc/json/soap api | 10:59 |
| jreese | I'd rather see two different events than force all plugins to do some complicated checks to make sure they're only running in appropriate contexts | 11:00 |
| Paul_46 | yea, but i'd probably be inclined to argue that the 'extra' event should be added as a sensible need arises | 11:01 |
| jreese | ie, one set of events for "headless" events that happen via APIs, and a complimentary set for UI events that allow plugins to display output, form elements, and process user input | 11:01 |
| Paul_46 | for example: EVENT_MANAGE_VERSION_CREATE | 11:02 |
| jreese | well, of course not every single event needs to be duplicated | 11:02 |
| Paul_46 | "This event allows plugins to do post-processing of newly-created project versions from the View Project page, or versions copied from other projects. This event is triggered for each version created." | 11:02 |
| Paul_46 | we need an EVENT_VERSION_CREATE in your context | 11:02 |
| jreese | but at this point, I don't think any good solution is possible without breaking everything that already exists | 11:03 |
| Paul_46 | i'm not too fussed about that | 11:03 |
| Paul_46 | as the 2.0 db api already breaks stuff | 11:03 |
| jreese | and given my current position with the project, tbh I don't really care what the end result is, I just think erring on the side of more events helps to keep the plugin hooks simpler by reducing how much they actually need to do to the minimum | 11:04 |
| Paul_46 | nod | 11:04 |
| Paul_46 | it's unfortunate that the plugin api hooks were created to match the setup of mantis - as whilst some of the events are great some are kinda wierd :) | 11:07 |
| jreese | yeah, the problem of working more towards direct goals and needs rather than a blue sky approach | 11:08 |
| Paul_46 | we should fire a hook really before/after any db change | 11:10 |
| Paul_46 | and then on some forms | 11:10 |
| Paul_46 | the first 2 allow for a) log plugins b) someone to enforce a rule e.g. capitalise users full name regardless of input source | 11:11 |
| Paul_46 | the 2nd is for the specific display issues | 11:11 |
| Paul_46 | e.g. provider user info | 11:12 |
| Paul_46 | -r | 11:12 |
| Paul_46 | the only question then is if you need [and you may do] | 11:12 |
| Paul_46 | plugin to hook html to add field to form | 11:12 |
| Paul_46 | event to hook response from form | 11:12 |
| Paul_46 | api->create function: | 11:12 |
| Paul_46 | event to hook before db insert | 11:13 |
| Paul_46 | event to hook after db insert | 11:13 |
| Paul_46 | or whether 'hook response from form' can be handled by 'before db insert' | 11:13 |
| Paul_46 | [you could always do a switch case (pagename) if you wanted to do certain thins on certain paths into the app only | 11:13 |
| GitHub180 | [mantisbt] rombert pushed 1 new commit to master-1.2.x: http://git.io/xNmzDw | 12:51 |
| GitHub180 | [mantisbt/master-1.2.x] api soap: correct usage of bugnote_set_view_state - Robert Munteanu | 12:51 |
| GitHub148 | [mantisbt] rombert pushed 1 new commit to master: http://git.io/ksCA2w | 12:51 |
| GitHub148 | [mantisbt/master] api soap: correct usage of bugnote_set_view_state - Robert Munteanu | 12:51 |
| *** Joins: giallu (~giallu@fedora/giallu) | 13:14 | |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 276 seconds) | 15:15 | |
| *** Quits: Paul_46 (~IceChat09@cpc1-enfi15-2-0-cust580.hari.cable.virginmedia.com) (Quit: Light travels faster then sound, which is why some people appear bright, until you hear them speak) | 16:32 | |
| *** Quits: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 17:00 | |
| *** Joins: sdfjkljkdfsljkl (~sdfjkljkd@static.96.23.63.178.clients.your-server.de) | 17:00 | |
| *** Joins: kirillka (~Miranda@195.242.142.17) | 22:31 | |
| *** Joins: giallu (~giallu@fedora/giallu) | 23:33 | |
| *** Quits: kirillka (~Miranda@195.242.142.17) (Ping timeout: 252 seconds) | 23:42 | |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!