[WIP][MIG] Migration of project_scrum to 10.0

[daramousk]

Takes things over from #1

[pedrobaeza]

There are .bzr files inside i18n

[daramousk]

what I miss in this module are decidated security groups for the different roles in a scrum project and the UI reactiving to that.

@hbrunn Can you be more specific here? I have added the three roles that exist on scrum but I am unsure as to which views/fields should they be able to view.

[hbrunn]

you're more into scrum than me, so I think your opinion is as good as mine. I assume owner and/or the master should be able to create and change user stories, change states there and such, and scrum users should only be able to change whatever it is they change. Some of the buttons probably are only relevant for certain roles too I guess

[daramousk]

@hbrunn Some of the security guidelines were already implemented and I have made some changes as well, got some help from @lfreeke. Tests successful as well.

[lfreeke]

@daramousk Create a separate task view for scrum projects. In case people are using both scrum and non scrum projects. You now see the scrum fields in the task tree view. I think it clearer for the user when it is separated.

[hbrunn]

it might make sense to do the same for projects themselves too. Then you can do nifty stuff like also passing a different view in the tasks button on the form, and have a different kanban/tree view vor them too.

Implement using a primary view override, this way you don't have to recreate everything from scratch but basically don't have to change much from what you have now

[hbrunn]

PS: also think of nice stuff like setting default_use_scrum and the like in the context of the actions you add

[daramousk]

@lfreeke @hbrunn This functionality already exists though, you can see the Use Scrum? boolean which you can toggle both on project.project and project.task. It shows only the relevant views. Is this not working properly? Or should this functionality refactored?

[hbrunn]

there are several problems with the current approach:

• the treeview for tasks shows a lot of unnecessary column for non-scrum-tasks
• hidden columns (and fields) still cause access errors for people who have project permissions, but no scrum ones
• use_scrum for a task should inherit this from the project, a standalone scrum task doesn't make sense

And of course if we have custom views for the scrum records we can do fancy stuff there that we couldn't properly do when having to keep the dual use form.

So just add a projects menu under the scrum item, and in the standard form only add the use scrum to the standard form so that we can create scrum projects either way. Under the scope of the scrum/projects menu, that should be the default.

[daramousk]

@NL66278 A review here as well if possible please.

[daramousk]

@NL66278 Can you tell me which functionality here requires hr_timesheet? I have removed it and everything seems to work fine, I have changed the name as well.

[NL66278]

@daramousk You are dependent on hr_timesheet, because you use the effective_hours added by hr_timesheet to project.task. Your present code crashes when trying to open sprints.

[daramousk]

@NL66278 The functionality that has to be removed is quite big though, the effective_hours is used in a couple of places among them. Also, the calculation of progress needs it.

The effective_hours is needed to calculate the progress of the sprint and the progress is essential to be known as per the sprint guide https://www.scrum.org/resources/what-is-a-sprint-in-scrum

[NL66278]

@daramousk I realise that effective_hours is the base of a lot of functionality. My proposal was not simply to remove it, but to put it in a separate module that is autoinstall when both hr_timesheet and project_scrum are installed. The real problem, which we can do nothing about for the moment, is that hr_timesheet should never have been dependent on accounting. On the other hand, we have been perfectly happy using scrum without doing anything with checking progress based on hours burned. We can also gauge progress by wether the issues assigned to a sprint are actually resolved.

[daramousk]

@NL66278 Removed this functionality

[daramousk]

@hbrunn Possibly this is ready for merge?

[daramousk]

@hbrunn Implemented all the changes