fschopp/project-planning-for-you-track

Library for project planning from YouTrack data. Retrieve past project schedule from activity log, and compute future schedule from unresolved issues and the available contributors.

project-planning-for-you-track's Issues

Safari 12.1.1: All text fields empty after login to YouTrack

Unfortunately, localStorage and sessionStorage seem to be unreliable in some browsers. Safari 12.1.1 exhibits a similar behavior as described in this StackOverflow post. Both localStorage and sessionStorage sometimes appear empty if our function handlePotentialOauthRedirect() is called “too soon” (and they remain empty while staying on the same page). Unlike hypothesized in the StackOverflow discussion, however, the issue in Safari still occurs when this function is called only after the DOM-ready event. The workaround mentioned on StackOverflow -- accessing sessionStorage.length -- does not help.

Interestingly, after one or sometimes multiple reloads (in the same window/tab), Safari suddenly does show the expected key/value pairs (as expected in the first place -- since we previously created them in goToOauthPage()). Since Safari switches to a new process when goToOauthPage() sets window.location.href, it’s possible that instead of the new process accessing sessionStorage “too soon,” it is actually the previous process that persists sessionStorage “too late.” Indeed, Safari writes sessionStorage updates to disk with a delay of up to 1 second:
https://trac.webkit.org/browser/webkit/releases/Apple/Safari%2012.1.1/WebKit/UIProcess/WebStorage/LocalStorageDatabase.cpp#L235

Other relevant source code in WebKit:

• https://trac.webkit.org/browser/webkit/releases/Apple/Safari%2012.1.1/WebCore/storage
• https://trac.webkit.org/browser/webkit/releases/Apple/Safari%2012.1.1/WebKit/WebProcess/WebStorage

The following FIXME in the WebKit code could be a contributor to the problem, too:

• https://trac.webkit.org/browser/webkit/releases/Apple/Safari%2012.1.1/WebKit/WebProcess/WebStorage/StorageAreaMap.cpp#L193

Interestingly, the FIXME suggestion could be done easily, given this changeset:

• https://bugs.webkit.org/show_bug.cgi?id=182021

There is also another StackOverflow post mentioning the above StackOverflow post (though no conclusive answer, either).

Exclude resolved issues from warnings

The generated ProjectPlan contains warnings about issues that, even though not contained in the saved search themselves, are the parent, subissue, or dependency of another issue that is. The rationale is that the project plan may be unreliable if it ignores these issues. For instance, if a dependency is unresolved but not included in the saved search (and thus is omitted from the project plan), then it is unknown when this dependency may finish (so ignoring it is unreliable).

However, some of these warnings are currently "false alarms". For instance, if a dependency is resolved, then ignoring it from the project plan is safe.

The project plan warnings should not contain false alarms.

Assignee changes in activity log

Currently, all past activities are treated as having been worked on by the current assignee of the issue. However, the assignee of an issue is not necessarily fixed. The activity log should be used to correctly attribute each issue activity to the real assignee at that time the work was done.