Bug :: Task.duration failing on read. (4.0.2)

Automation OmniPlan Automation
#1

In OmniPlan 4.0.2 (v205.7.0) reading Task.duration fails.

Writing works well – we can set a task’s duration, and the results are visible in the GUI, but as a getter, evaluation of .duration invariably returns only null values, even for tasks that do have duration values.

(regardless of whether these durations have been set through the GUI or the API)

Example:

We can create the following data by script or GUI, but the .duration value for each task is invariably reported to be null

Screenshot 2020-09-04 at 11.27.39
Screenshot 2020-09-04 at 11.27.39974×430 36.5 KB

const test = () => {
    const
        rootTask = document.project.actual.rootTask;

    [1, 2, 3, 4, 5].forEach(
        h => {
            const newTask = rootTask.addSubtask();

            newTask.title = h.toString() + ' hours';

            // WRITE/SET SUCCEEDS
            newTask.duration = Duration.workHours(
                2 * h
            );
        }
    );

    // READ/GET FAILS
    return rootTask.subtasks.map(
        task => null === task.duration
    );
    //-> [true, true, true, true ...]  :-(
}
1 Like
#2

This is still the case in 4.8.2 (v225.0.116)

#3

Important to flag that to support - I don’t think they read these forums

#4

I have done. Thanks.

#5

@kcase

This API bug, Task.duration failing on read was first reported in 2020, for Omniplan (4.0.2)

(See the top of this thread)

Bug :: Task.duration failing on read. (4.0.2) - Automation / OmniPlan Automation - The Omni Group User Forums

This morning, Jun 17 2024, I get a note from your support team, thanking me for a reminder, in these terms:

I added you to the bug report so the team knows you were hitting this bug as well.
Thanks for helping us spot this automation bug

I really don’t think that a piece of administrative paper-work is a reassuring response after what will soon be 4 years.

The failure of that elementary piece of API made OmniPlan useless for what I needed in 2020.

Today, seeing the continuing level of neglect over 3 years, now approaching 4, I have realised that I simply need to uninstall it.

#6

My apologies that we didn’t communicate better in that support ticket! This bug was fixed earlier this week for the upcoming 4.8.3 release.

A test build of 4.8.3 which has this fix can be downloaded from https://omnistaging.omnigroup.com/omniplan/.

#7

I hope that helps @dainem

( for me, it’s over 3 years too late, and I would be wary of another project tripping over untested API, and again being stopped in its tracks by dilatory response)

#8

My apologies again for the slow response on that bug! Looking into the history of that bug, it looks like your initial report was filed as low priority because there wasn’t any indication that you were blocked by it, just a note that you had observed the bug.

The second person to encounter the bug (a year later) did ask for help resolving it, which is why the support team investigated in more detail and provided them with a workaround. But since the workaround solved the issue for that second customer, it was still considered a low-priority bug since we’d only only received two reports about the problem and a workaround was available.

When this bug was brought to our attention again earlier this week, the person triaging the report understood better how even a small bug like this might get in the way of someone trying to build automate scripts. So he asked engineering about it, and it was immediately fixed.

I’m sorry that our initial triage of that bug didn’t identify that it was making the app less usable for people writing scripts!

For anyone reading this in the future, please don’t hesitate to tell us when a bug—no matter how small—is making your life more difficult. Knowing how a bug affects your use of our app helps us do a better job of understanding how important it is relative to other bugs that have been reported.

Thank you!

#9

Good heavens