On 9/3/13, Ben <[email protected]> wrote: > On my Bloodhound 0.7 install, when click on modify ticket, I cannot modify: > > Product > Assigned to (owner) > > Looking at ticket #647 <https://issues.apache.org/bloodhound/ticket/647> > I see someone asking about this with regard to changing the product. But > I'm confused about what is said in the ticket. It seems to say > > a) that is complicated and can't be done until we finalize some ticket > stuff > b) here's how to do it. > > b) involves a batch edit of tickets, and that seems to work fine in my > experience (for both changing product and owner). > > So, is there any reason not to have the modify ticket page let you do > these changes as the backend is already implemented (I believe) as it > can just be a batch change of one ticket. Is it just that this hasn't > been implemented yet, or are there larger issues? (I guess changing the > product is tricky as it changes the url to the ticket, but I think a > warning would be sufficient.) Changing who is assigned the ticket seems > straight-forward. >
The hack involving batch modifications for products is not exactly a feature but the result of applying the same modifications defined by legacy Trac code upon selectes tickets , considering the fact that product is yet another field . I actually «discovered» this while playing with the functional test suite . I only use it 1. as a last recurse to correct mistakes 2. to move spam onto a trash product Nevertheless moving tickets to a different product implies few other things not actually performed by batch modify (especially in 0.8-dev after committing code for consecutive per-product ticket IDs) since it's also needed 1. to keep track of such local IDs 2. render redirection page ... 3. (maybe) migrate further metadata e.g. fine-grained permissions 4. [...] maybe more side-effects > Re: Proposals/BEP-0010 > <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0010> which is > referenced in the ticket. For what it is worth, I think Alternative 1 is > quite nice. I would add an admin setting to select which of the two > ticket referring methods to use for links from within bh: > > /env/ticket/<ticket-id> -> (ticket-id) -> ticket > vs > /env/products/<product-prefix>/ticket/<scoped-id> -> (product-prefix, > scoped-id) -> ticket > > as then you can choose it ignore product scoping if you want (I never > want my urls to change and I don't want anyone linking to ones that > might) or you can use it (maybe restricting access to some products at > the web server level, cleaner url separation). > yes , product-prefixed URLs are almost mandatory for sub-domain deployments, afaict . Per-product ticket sequences are required to populate products by import tickets formerly managed elsewhere . Under certain circumstances a single global sequence is just enough . The fact is , how to deal with both cases e.g. when thinking about inter-product vs local ticket: TracLinks ? > (I'm really liking BH so far -- thanks everyone -- :) > not being able to > (easily) modify the owner of a ticket is the only hiccup I've come > across so far, which is great) > owner modifications must go through workflow . There's an action to assign ticket to a given user . Depending on your workflow definition it's possible to have states in which modifying owner might not be allowed without applying certain side-effects . All these decisions are configured in transitions and rules . [...] -- Regards, Olemis - @olemislc
