Workflow change project #223
Conversation
if you're not sure how, you could add two methods:
so you can choose which one to implement. |
|
Good idea. I've done that now. I'll do a bit more testing before merge. Since ChangeLog is conflicting now, should I rebase once everything is good to go? |
|
i'm planning to make release shortly, so it will conflict even more. and this PR should be merged after the release, to give it more testing ground. so yes, rebase after release made (and fix |
| * @since 3.1.6 | ||
| * @return null |
There was a problem hiding this comment.
it doesn't return anything. remove this line
| * @param $issue_id | ||
| * @param $old_prj_id | ||
| * @since 3.1.6 | ||
| */ |
There was a problem hiding this comment.
as minimum, should fill param types
|
relased, you may rebase now |
balsdorf
force-pushed
the
workflow_change_project
branch
from
ce47ee0
to
2e48236
Compare
…vedTo. Changed getMovedIssueMapping method to be called and workflow class of new project.
balsdorf
force-pushed
the
workflow_change_project
branch
from
2e48236
to
c0a2a4e
Compare
|
Well I royally made a mess with git but I think I managed to fix it all. |
|
you can see the Commits tab (https://github.com/eventum/eventum/pull/223/commits) what are the actual commits associated, looks good right now. |
This can be used to map values for fields between projects or do other custom changes.