Got result 0/0 docs while clicking in area with “5” emails?

[Peter Chan]

Yeah, I think its not worth the significant re-engineering to handle this corner case properly.

What are the conditions under which we might say 0/0 messages? We should give appropriate error messages:

No messages found. (The session may have been invalidated). -- if we're not sure.

The session has been invalidated -- if we are sure that's what happened.

Related:

I think a more likely problem is a user clicking a link when the session times out (e.g. user came back the next day and clicked on a link in an open browser window).. In this case, we should avoid giving the error screen and instead give a session timed out message.

[s]

On Sat, Nov 24, 2012 at 6:55 PM, Chaiyasit (Sit) Manovit  wrote:

Hi Peter, Sudheendra,

Regarding this bug on Pivotal Tracker where clicking on a chart returns zero documents where 5 are expected (https://www.pivotaltracker.com/projects/694537#!/stories/39962119), this happened because two different archives were concurrently loaded under the same web browser, supposedly in different tabs, and Muse would only operate with the most recently loaded archive. But the search that triggered the bug was performed on the non-recent, stale archive session. The bug's screenshot showed that it was the chart of Creeley's archive but in fact Muse was actually using and showing the data from Fike's archive, which was indeed the most recently loaded session (per Muse's log file of those activities which has been retained on the server).

The question here is whether we want to allow users to work on multiple archive sessions under the same web browser at the same time. If so, this bug will be deemed critical which would involve a fundamental change in Muse's handling of web connections (probably has to be made RESTful). Otherwise, this can be counted as not a bug, but we may still need to better handle this situation to let users know the correct session they are actually seeing. I guess the latter is more convenient for us at this stage.

Thanks,

--Sit

[Chaiyasit (Sit) Manovit]

On Sun, Nov 25, 2012 at 12:00 AM, Peter Chan <peter...@gmail.com> wrote:

Yeah, I think its not worth the significant re-engineering to handle this corner case properly.

What are the conditions under which we might say 0/0 messages? We should give appropriate error messages:

No messages found. (The session may have been invalidated). -- if we're not sure.

The session has been invalidated -- if we are sure that's what happened.

The problem needs not be just "0/0", but it can also be "x/y" from a "wrong" archive. For example, user may have one browser tab looking at the search result of "ruth" on Creeley's archive and decide to open another tab to load Fike's archive but then go back to the Creeley tab and click on the chart - this will bring up the message browser frame in the Fike's archive instead of Creeley's, which is "wrong". Without any changes, I'm not sure how to detect this case because the message browser frame is oblivious to what archive is being shown by the chart and it instead always operates on the most recently loaded archive. I propose to have the chart page pass a request parameter to the browse frame to indicate which archive to operate. We can then have the browse frame either load the requested archive or detect the discrepancy and give an error message.

 

Related:

I think a more likely problem is a user clicking a link when the session times out (e.g. user came back the next day and clicked on a link in an open browser window).. In this case, we should avoid giving the error screen and instead give a session timed out message.

It seems this is already happening. But the timed out message is currently always pointing to the classic /muse/index.jsp which is not the appropriate page for ePADD UI. I will fix that.

Thanks,

--Sit

[s]

On Sat, Nov 24, 2012 at 6:55 PM, Chaiyasit (Sit) Manovit  wrote:

Hi Peter, Sudheendra,

Regarding this bug on Pivotal Tracker where clicking on a chart returns zero documents where 5 are expected (https://www.pivotaltracker.com/projects/694537#!/stories/39962119), this happened because two different archives were concurrently loaded under the same web browser, supposedly in different tabs, and Muse would only operate with the most recently loaded archive. But the search that triggered the bug was performed on the non-recent, stale archive session. The bug's screenshot showed that it was the chart of Creeley's archive but in fact Muse was actually using and showing the data from Fike's archive, which was indeed the most recently loaded session (per Muse's log file of those activities which has been retained on the server).

The question here is whether we want to allow users to work on multiple archive sessions under the same web browser at the same time. If so, this bug will be deemed critical which would involve a fundamental change in Muse's handling of web connections (probably has to be made RESTful). Otherwise, this can be counted as not a bug, but we may still need to better handle this situation to let users know the correct session they are actually seeing. I guess the latter is more convenient for us at this stage.

Thanks,

--Sit

--
 
 

[Chaiyasit (Sit) Manovit]

sulmuse-dev:9099 has been updated with a fix (still incomplete for clickable links inside a message which still open message browser on the recently loaded archive rather than the intended one - fix for this will be deferred to when we reorganize the archive data structure).

Thanks,

--Sit