Closed spazm closed 12 years ago
retorquere
commented
13 years ago This is a much-requested feature. Unfortunately we currently don't have a front-end developer, and the solutions proposed earlier were incomplete. As soon as I get time (ha!) to dive into the front-end it's high on my priority list.
yquenechdu
commented
13 years ago Hi,
Could you tell me what you look like front-end developer in terms of competence
Cheers Yannick
retorquere
commented
13 years ago Availability and enthusiasm :).
If you know javascript and html you're golden. On Oct 6, 2011 2:19 PM, "yquenechdu" < reply@reply.github.com> wrote:
Hi,
Could you tell me what you look like front-end developer in terms of competence
Cheers Yannick
Reply to this email directly or view it on GitHub:
https://github.com/relaxdiego/redmine_backlogs/issues/95#issuecomment-2309131
pinkcherub
commented
12 years ago Hi,
We would like to have this feature too - is there any update on your progress with it?
We have versions/sprints created in a master redmine project and when we allocate an issue from a sub project to it we would like the issue to appear in the backlog of the master project.
Cheers, Sam
retorquere
commented
12 years ago I'm keeping the "sharing" branch, which implements the basics for this, up-to-date with master, but I'm not releasing it until I have some test coverage. I don't have the time to do both master-branch maintenance and writing tests for sharing (job, family, masters study), so the branch is entirely unsupported until someone starts writing on these tests. Right now, it might work, it might not. (you can safely consider this to be an invitation to help out on this. It's not hard, but it does take time)
pinkcherub
commented
12 years ago Ok thanks. We'll take a look at what you've done and see if we have any resource that might be able to help.
bohansen
commented
12 years ago I briefly dived into the sharing branch. I get the following output from running the tests: https://gist.github.com/2056741
It doesn't look too bad, but I'm wondering why commit f2733e67 introduced e.g. "And I have defined the following stories in the following sprints:" whereas the master-branch uses "And the project has the following stories in the following sprints:"? Any particular reason for this or can I change it back? There are a few similar renaming issues.
retorquere
commented
12 years ago Best to change it in the master branch then. The sharing branch introduces the concept that a story can be part of a sprint that is not part of its own project. In the master branch then project for the issue is simply taken from its sprint.
bohansen
commented
12 years ago I see, there was a good reason why they were renamed ;-). I tried to run the sharing branch but got a "wrong number of arguments (3 for 1)" for .redmine_backlogs/app/models/rb_story.rb:83:in `backlog'. It's running now using the following patch (https://gist.github.com/2098602), but I'm not sure it's the correct solution. Let's say I have a structure of a top project and two subprojects. When I show a subproject the product backlog only shows the stories of the subproject. That's what I expected. However each of the sprints also show stories from the other subproject. Is that correct? In some situations it might be desirable, but I'd like to think that when I want to see all stories of subprojects I go to the top project view. Just want to align what I should expect before I look more closely at the backlogs/sprint functions in rb_story.rb.
retorquere
commented
12 years ago On Mon, Mar 19, 2012 at 8:12 AM, bohansen < reply@reply.github.com
wrote:
I see, there was a good reason why they were renamed ;-). I tried to run the sharing branch but got a "wrong number of arguments (3 for 1)" for .redmine_backlogs/app/models/rb_story.rb:83:in `backlog'. It's running now using the following patch (https://gist.github.com/2098602), but I'm not sure it's the correct solution.
Yeah, I think that's correct. Feel free to push straight to the sharing branch; it's going to be test-and-fix for that anyway.
Let's say I have a structure of a top project and two subprojects. When I show a subproject the product backlog only shows the stories of the subproject. That's what I expected.
That is correct.
However each of the sprints also show stories from the other subproject. Is that correct?
It is if, for example, you have this setup:
Top project, with sub project A and B. Top project has shared sprint Sp A has story S1 on sprint Sp B has story S2 on sprint Sp
In that case if you look at Sp in the context of A, you will also see S2. But those should be the only ones.
In some situations it might be desirable, but I'd like to think that when I
want to see all stories of subprojects I go to the top project view. Just want to align what I should expect before I look more closely at the backlogs/sprint functions in rb_story.rb.
I think you have the right picture in your head.
bohansen
commented
12 years ago Almost got the tests running on the sharing branch. The "impediment"-tests are causing me some trouble (what a coincidence ;-)).
Couldn't find Project with ID=0 (ActiveRecord::RecordNotFound)
./app/models/project.rb:250:in find' ./vendor/plugins/redmine_backlogs/app/controllers/rb_application_controller.rb:19:inload_project'
/usr/lib/ruby/1.8/benchmark.rb:308:in realtime' ./features/step_definitions/_when_steps.rb:2:in/^I (try to )?create the impediment$/'
features/scrum_master.feature:36:in `When I create the impediment'
expected not nil, got nil (Spec::Expectations::ExpectationNotMetError)
./features/step_definitions/_then_steps.rb:114
./features/step_definitions/_then_steps.rb:113:in each' ./features/step_definitions/_then_steps.rb:113:in/^the sprint named (.+) should have (\d+) impediments? named (.+)$/'
features/scrum_master.feature:46:in `Then the sprint named Sprint 001 should have 1 impediment named Good Impediment'
expected #has_content?("Impediment 1") to return true, got false (Spec::Expectations::ExpectationNotMetError)
./features/step_definitions/web_steps.rb:110
./features/step_definitions/web_steps.rb:14:in with_scope' ./features/step_definitions/web_steps.rb:108:in/^(?:|I )should see "([^"])"(?: within "([^"])")?$/'
features/scrum_master.feature:54:in `And I should see "Impediment 1"'
Failing Scenarios: cucumber features/scrum_master.feature:31 # Scenario: Create an impediment cucumber features/scrum_master.feature:40 # Scenario: Update an impediment cucumber features/scrum_master.feature:48 # Scenario: View impediments
The first I got around by adding project-context when initializing impediment parameters, and the second one I got around by putting the status ID into the parameters in stead of the status object itself. However the last one I couldn't figure out. Somehow the impediment "Impediment 1" does not show up when viewing. I have not committed any fixes for these three issues as I thought they might be related?
/Bo
retorquere
commented
12 years ago I've just pushed a change to the sharing branch that ought to fix problem nr 1, the rest are knock-on effects I think. The impediment gets created on the same project as the sprint, unless you specify in in the creation line ("When I create the impediment on project X"). Untested, sorry. (crazy busy once again)
bohansen
commented
12 years ago Thanks, I checked in a few extra fixes - turned out the "And I have defined the following impediments" was not creating impediment for the correct sprint. Anyhow the tests are passing on the sharing branch now. Time to think about some new tests...
martin-denizet
commented
12 years ago I'm looking forward to see the support for subprojects. In my organization, large development projects are split into subprojects. How can I help with this issue?
bohansen
commented
12 years ago I got the tests working a few weeks ago, but it needs more tests regarding the sharing stuff. As far as I know the taskboard still needs some work as moving tasks from one story to another is currently disabled. In the master-branch moving tasks between stories is legal. It should be decided (and implemented) if this will be legal between shared sprints as moving tasks potentially involve moving a task to another project. @friflaj has written more about this here: http://www.redminebacklogs.net/en/roadmap.html
The sharing branch should be stable enough to give it a spin and see what you think about it. I've listed a few issues I think worthwhile to discuss below:
On the master backlog you can change priority of each story in each subproject. If you put another story on top in a subproject that story will be highest priority in the topproject no matter what priority any story of the subproject had before. I don't know any good solution to this, but I can imagine if different teams are controlling each subproject the product backlog for the topproject will be pretty useless as it will basically be the subproject edited latest on top. It might be fair to say that it only makes sense to control the priority in one place, but then we need some protection from messing up the list in the other end.
Another thing which puzzles me is already discussed a bit in this thread. When you view the master backlog for a subproject each product backlog will only show items from that subproject. However all the sprints will show stories from all projects in that sprint. When using the "shared with subprojects"-approach at least I think it would be more natural that only the top project shows stories for all subprojects.
retorquere
commented
12 years ago I'm a bit blurry -- I haven't been in the sharing branch for a long time, and I've just resurfaced from the quartile from hell. The plumbing to restrict drops to valid targets is all there on the backlogs screen, so whatever behavior we need can probably be implemented without too much problems. The same plumbing ought to be transplantable to the task board, and I'd propose we just be super conservative for a start -- only dropping tasks on stories from the same project.
patrickatamaniuk
commented
12 years ago I'm working on that feature. My impediment: i put several hours into identifying regressions which occured due merging master into sharing. I can offer to maintain the sharing so it keeps aligned with master. On the way more tests will emerge for that branch. This way i'd get around inside the code and be able to ensure that the tests and functionality stay green on sharing.
retorquere
commented
12 years ago @patrickatamaniuk deal! You want me to stop merging master into sharing?
patrickatamaniuk
commented
12 years ago yes, i'd like to give it a try to work on sharing and keep it aligned to master - albeit i'l need help here and there :-)
retorquere
commented
12 years ago No problem on the help! I'll keep my hands off the sharing branch; as soon as a basic test set passes (feel free to hack around) we'll add it to the Travis build
patrickatamaniuk
commented
12 years ago I believe it is ready for alpha testing. There still are many more testcases to be written - but if i could have any feedback where the rough edges are, i'd concentrate new tests there.
Also i plan some refactoring to get the diff against master minimized. I'll see.
The 'new story' menu on sprint backlogs is working, but conceptually not finished. Currently i implemented 'you can create stories in any project where the sprint is shared'. That might be confusing, as globally shared or tree/hierarchy shared versions seem unrelated to the currently visible project or product backlog. We could try to 'you can create new stories in any project within the scope of the current product backlog' - that is subtree. Probably i've to ponder and draw some scenarios to ask users about that.
patrickatamaniuk
commented
12 years ago Here i need help: features/shared-versions-burndown.feature setting up the tasks in Background: Story C shall be in a subproject but in the main projects sprint. Now i cannot get task C.1 created in a way that the burndown - which uses .descendants - will account for it. I took care that the task should get created in the same project as the story. Preliminary analysis indicates that C.1 is not properly added to C as child. I have no clue if it is a setup problem with the test, a permission issue perhaps or what else.
Edit: this does not happen with phantomjs driver. weird.
svolpe
commented
12 years ago Patrick, I just installed your version of redmine backlogs and will do some testing on it. Anything specific you would like tested? Also do you know how close you are to pushing it into the mainline redmine backlogs?
patrickatamaniuk
commented
12 years ago Svople, thanks so much for your support.
Anything needs to be tested :-) Basic usage, working on backlogs, working on taskboard, keep an eye on the burndown, and any unexpected behavior would be interesting. Javascript errors should not occur. Drag and Drop should not break or suddenly stop working. Order of stories within the backlog page should be consistent and should behave non-confusing for the product owner.
Migrating stories/tasks across projects could be a use-case to test, too.
Furthermore im very interested in how and why you would use sharing - multiple projects, teams, scrum of scrums, organizational scrum etc.
Please note: sharing currently needs to be enabled on the plugin settings page. The default mode then is to obey the redmine versions sharing logic: a sprint can only receive backlog items from projects where it is visible by redmine version sharing. It also might be useful if you enable 'manage sub-tasks' for your user and enable 'issues across projects' in the redmine main settings if you want to create impediments which block multiple tasks from different projects.
Please make backups of your database :-)
I have no concrete idea when the core team will decide to merge the branch - i suspect that some review-cycles and much fixing and tuning needs to take place first. I am currently writing extensive automated tests which need proper review, too.
retorquere
commented
12 years ago The existence of test coverage comparable to what we have, plus user feedback such as this, would do it for me. I'm not setting any higher standards for the sharing branch than exist for master - I want sharing merged, and master is find-and-fix, too. Main driver is really that I can find-and-fix, hence the tests.
bohansen
commented
12 years ago The sharing branch have changed a lot since I tried it last time. I gave it a spin under redmine 2.0.3 and have a few comments:
Master backlog
Drag/drop (master backlog)
Drag/drop support between stories in taskboard view
Tracker statistics tooltip (master backlog)
Use cases for sharing
The way sprints are shown I think the sharing branch currently is best suited for tightly coupled projects. When showing the master backlog for a subproject you also see the content of the sprints for all other projects sharing this sprint. Offhand I'd say this detailed view is only interesting if it's the same SCRUM team working on this group of projects.
All in all it's looking very promising.
/Bo
patrickatamaniuk
commented
12 years ago Thank you, @bohansen
Move stories between product backlogs: use context menu in redmine standard view to edit a bulk of stories and change project. This will also pull existing tasks. (not sure if burndown will break, though)
New Story indentation: yes, the menu's usability is suboptimal (1), its the first draft from ages ago :-) DnD on backlog: yes, valid bug here. jQuery DnD is pain, though. (1) DnD on taskboard: to ease up the first implementation it was decided to limit dragging inside the story (see forum). For me, it has the advantage that i do not accidentially change the story of a task. Technically, the old behavior could be supported with a little effort. Personally, i'd vote for "not neccessary"
Decoupling: I think about configurable views for the master backlog page, where i can a) configure per project which sprints of others i want to see (if any) b) configure per "use-case view" what i can see where This would add flexibility and widen the use-cases where the master backlog page is useful. If you use much tree or system sharing, then a large installation currently will be quite crowded. My place is currently testing with hierarchy/subtree only sharing and it seems to be viable, given the projects are structured accordingly.
(1) I deferred all frontend changes until sharing is mainline, since merging will become painful otherwise.
bohansen
commented
12 years ago Regarding moving stories I meant changing position in the product backlog. E.g. change relative position of all stories of a subproject. I don't have any good idea how this should be done. Anyhow it's a "nice to have".
I agree on the UI changes. They can easily be postponed until merged.
Sounds like a good idea with a configurable view on the master backlog. In stead of (or in addition to) selecting which sprints to show I think it could be interesting to be able to select which projects to include. This could be done like the multiple select on the taskboard enabling selecting/deselecting subprojects. But that's also a "nice to have". I'm not sure the detailed backlog view of several projects is interesting for anything but tightly coupled teams as I wrote in the last post. And in that case the current sharing view fits perfectly. When aligning two different teams I can better imagine the need to "synchronize" on releases. That part needs substantial work anyway. But I see no harm in merging the sharing branch before taking that discussion.
From a feature/usability point of view I'll vote for a merge of sharing. I can't say about the tests and refactoring though.
/Bo
retorquere
commented
12 years ago If sharing seems feature-wise stable and not a functional regression from master, I'd say it's time to merge. The sharing branch is going through the travis build now, it would mean much to me if someone could make sure sharing merges cleanly back to master before I actually go ahead an do it. Sorry I've been so absent lately, still swamped.
retorquere
commented
12 years ago The build currently breaks on 1.8.7. It's not a huge priority (I've switched to 1.9 myself), but if it's an easy fix...
patrickatamaniuk
commented
12 years ago i'm on integration atm. build works for me at 1.8.7. test merge is running on travis, i'll offer the pull then.
retorquere
commented
12 years ago Closed, because it's finally merged!
bohansen
commented
12 years ago Tests are working here also - looking forward to start using it ;-). Thanks a lot!
I would like to see the issues/stories from sub-projects in the backlogs display for the parent project.
We use multiple sub-projects to maintain multiple git repositories, but they are all related to a common parent project. We are planning our sprint at the parent project level.
Suggestions on where to make this modification would be appreciated. It looks like we'll want logic using the project.lft, project.rgt fields when calculating the self.condtion in app/model/story.rb, likely modeled after the redmine base code in app/models/project.rb?
Thanks, Andrew