-
Notifications
You must be signed in to change notification settings - Fork 29
Filter workflow by roles used in project #14
base: master
Are you sure you want to change the base?
Conversation
Call function from issues view
Changes in lib
@@ -31,7 +32,7 @@ | |||
|
|||
<script type="text/javascript"> | |||
$(function() { | |||
var json = <%= WorkflowEnhancements::Graph.load_data(roles, trackers, issue).to_json.html_safe %>; | |||
var json = <%= WorkflowEnhancements::Graph.load_data(roles, trackers, issue, project_roles).to_json.html_safe %>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't calculate project_roles in the view, just pass the @project
object and do things in the Graph.
I understand why you want to do this, but it's only a half-solution. Sure for the project view it's all better, but for the admin view it's no change. So...I don't know if I like it. Having one workflow name with different groups of roles to form completely different workflows for different projects sure works technically, but I think you would be better off just giving the workflows different names. It sure must be a nightmare to manage. The reason I did the plugin in the first place was the graph in the administrator part of Redmine. I had to manage different complex workflows and needed something to make that manageable... |
Thank you for the tips. My company blocks git at the firewall for some reason, and I was having to edit patches in the html interface. Sorry for the mess, the html interface is very hard to use, I still don't know how to rebase in it. I have submitted patches to redmine to try to improve the admin interface. I think you can do little to improve the graph in the admin interface, because you would need all roles plotted on the graph. Unless it was possible to turn roles on and off in the graph interface, or separate workflows in something like workspaces (so you could have the same roles and trackers doing different workflows on different projects). In our company, development, management and infrastructure are using scrum in Redmine, so the workflow and number of roles differ greatly between areas. And everybody wants to use the plain "Story" tracker, so we were having very big workflows in development and very simple workflows everywhere else, and people working with small workflows would get confused. We are using different trackers besides different roles already. The workspaces solution would be better, but also harder to code. |
No Git access...that is horrible. Not even over HTTPS? If the browser connects via a proxy, you need to configure that for Git too. If it's that stupid proxy auto-config script stuff you have to use 'curl' or something (sometimes multiple redirects) to figure out the correct URL. Had to do it once at work when they messed up direct internet connection and only the proxy was working. Quite an unpleasant experience but I managed to get GitHub HTTPS push working. I see. Scrum. I'd still split "Story" to "D-Story", "M-Story" and "I-Story" or something. If you can't to that then turning roles on and off in the admin view would be a good solution, I agree. Just not so easy to implement as it should be stateful... You convinced me that this is the right direction. At least show the users something useful. If you clean it up enough, I'll merge it :) |
The graph in issues shows a workflow with all the paths the tracker can follow. In Redmines in which trackers have different workflows, depending on the project, the workflow shown becomes a mess of different workflows showing as one. This mess is the same image showing in Admin Workflow, but users should have a simpler image showing.
This patch filters the issue workflows to those used by the roles in the project.