Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ticket Moved (wrong status and wrong user at the destination) #2

Open
mrinterestfull opened this issue Jul 3, 2013 · 4 comments
Open

Comments

@mrinterestfull
Copy link

Hello,
I'm having problem with the git version. Before ticket is moved it is
closed as duplicate. Then its moved to a new trac. On the new trac it is
also closed, the username was moved but the user doesn't exist in the new
trac.

So the ticket is closed (nobody will see it), and nobody will be looking for it because its assign to a user that doesn't use that trac.

Can you update the ticket at the destination to:
1: move to new trac and set to user to "somebody"

  1. Move to new ticket and set as status new

    Let me know if that can be done.
    Thanks
    Lucas

@UnwashedMeme
Copy link
Collaborator

Before ticket is moved it is closed as duplicate. Then its moved to a new trac.

The plugin doesn't close the ticket as duplicate until after it is completely moved to the new trac. I can't see how it might have happened unless you mean the user manually closed it as duplicate before invoking the move action.

I added some more logging to the plugin if you want to try and see at what step it failed, or where the order of things might be going wrong.


  • Where should the configuration of the target user be stored: on the source Trac or destination Trac?
  • Where should the configuration of the target status be stored?

My best thought would be to store on the src trac either a whitelist of fields to copy or a blacklist of fields to not copy when doing the move and then let the destination trac fill in default values for anything not set.

I've always viewed this as the user's responsibility. Once you move the ticket you are given a link to the target ticket (or redirected in case of deletion). Click the link and fix it at that point.

@mrinterestfull
Copy link
Author

Hello
You were correct. It looks like user closed as duplicate before they moved. (No action required).

I do need a fix for the other part. The the task was assign to a user. At that point you can only reassign it to another user. We have a dedicated person that moves tickets between trac in each department.
Example:
User "tom" has a ticket assign.
He moves the ticket to other trac.
The ticket stays as assign to user Tom. Since there is no tom in the other trac the ticket stays in "limbo" untill somebody does active tickets by users and notices ..."what is this tickets for tom who is not in this trac"?

You said I could block out the username, and ticket status during move? How can I do that? The default trac.ini settings would then assign the ticket to "somebody" with status "new".

Thanks
Lucas

@UnwashedMeme
Copy link
Collaborator

Another thought on implementing this would be add configuration to the target trac:

[ticket-mover]
overwrite= <FieldName>:<Value>,...

or

[ticket-mover]
overwrite.<fieldname> = value
overwrite.<fieldname2> = value

And then if value is not None use that string, otherwise just reset that field to ticket default?

or maybe:

[ticket-mover]
blacklist_fields = field_name,...
whitelist_fields = field_name,...

I think both of those make sense more on the destination trac? or maybe a separate whitelist for source and destination (getting too complicated)?


PS: Part of your problem sounds like your ticket next status is to constrained; that can be customized http://trac.edgewall.org/wiki/TracWorkflow

PPS: obviously this is pretty low priority for me. I'll be happy to look over any patches and include them here if they're good but if you want custom development for this our anything else my company offers it: http://www.acceleration.net/programming/custom-solutions/

@axd1967
Copy link

axd1967 commented Mar 26, 2019

In Admin > Components, there is a list of components and their owner.
There is also a default component (and owner).

That looks like the owner to which the ticket should be reassigned?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants