bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Modify Ticket Options
Date Wed, 04 Sep 2013 04:25:05 GMT
On 9/3/13, Ben <> wrote:
> On my Bloodhound 0.7 install, when click on modify ticket, I cannot modify:
> Product
> Assigned to (owner)
> Looking at 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
> <> 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 .



Olemis - @olemislc

View raw message