How to manipulate multiple issues dates at once

Hello,

First, sorry my terrible english. Second, I'm not sure if I'm posting this question in the right place, so please kindly point me to the right place/documentation.

I put my hands on a (few) already started project(s) with a few hundred issues already created in a "ideas dump" fashion. All issues have the same start date (the project creation day), and a correct estimated time. Assuming that all the issues are parallel in nature, I would like to know if there is a (proper) way to:
1) Distribute multiple issues over a pool of days, redefining the issue start date based on the summation of the previews processed issues estimated time. So, for exemple, the third issue processed would be in the second day of reference, given the two issues before to be of 4h estimated time each, using a 8h/day pool of 3 days.

2) , Assuming that all the issues are already distributed in a pool of days, perform a simple shift in the start date of a issues subspace, representing a unanticipated delay like the server catching fire.

I know I could easily do it direct in the data base, but I am afraid of that the change of the date would be supposed to trigger somme action when done by the web interface.

The redmine version we are using is 3.3.3.stable.
Thanks in advance.

Replies (2)

RE: How to manipulate multiple issues dates at once. - Added by Bernhard Rohloff about 7 years ago

Hi,

do you need an automated solution, or just an idea how to structure your issues manually?

There is no workload limit or automatic issues management in Redmine. Estimated time, start date and due date have no relation to each other.
You could collect your issues for a workday in a parent issue. For this parent issues you could set the start and due date. With the "follows"
relation you could concatenate your issues to a chain of following work packages. Then your following issues would automatically move, if there's
a delay in a previous package.

For automation purposes there is Redmines REST-API which could be accessed by a script.
https://python-redmine.com/ would be my choice.

Kind regards,

Bernhard

RE: How to manipulate multiple issues dates at once - Added by Eduardo Bach about 7 years ago

Hi Bernhard

Thanks a lot for the reply.

On the subject of issues dependence as a solution to the time shifts problem:
Issues were already organized in subtasks, but parents do not represent goals in a timeline, but they organize issues by subject. They are organized at various levels and being able to look at this organization seems essential to the user. Another thing is that the parents were created with start and due date independent of the subtasks, and I do not know how to reapply this. Just changing the configuration in administration seems to have no effect on issues already created. That is why we have left this idea a little on the side and we were thinking of directly manipulating the dates of the existing issues. But with your suggestion we are reviewing this, as it seems that we will not be able to escape from recreating the parents. Anyway, with new parents, I still need a way to edit certain fields that will have values in common on various issues, like the parent issue id, otherwise I'll have to edit issue by issue to change this value. It seems to me to be essentially the same problem to solve by editing the start dates directly on the sub-issues.

To make these changes in bulk, I'm playing around with the rest-api you indicated, with php, but I still have some work to do to get it done in a really reusable way. In the meantime, I will try to answer the following question: Sub-issues always represent concrete work to be done. Explicitly organizing the sub-issues on workdays, with parents dependencies, gives the user (developer) a vision of the daily work that needs to be done, and for me a way to dynamically adjust this. Given a different organization of sub-issues, how do they get this same insight into the daily work to be done? I was trying to implement this in "scheduler" way, distributing the issues in time slots by controlling the issue start date, but as you pointed out, the lack of dependencies between the issues makes the drawdown on the initial distribution very difficult.

Best regards,
Eduardo

(1-2/2)

Project

General

Profile

Redmine