Description of problem: There are cases when cumin can't find the object user requested. In this case cumin gives following message: We can't find the object you requested This often happens when a far-off agent stops or is disconnected. It may come back under a different database ID. Try navigating anew from the site root. Better option would be if cumin can navigate user to one widget back to closer page than the site root is. Maybe it needs to track for this purpose user browsing history. Example: Bug 783139, comment 0 Jump from: Grid::Submission::JOB1 into Grid::Submission (not site root) Version-Release number of selected component (if applicable): cumin-0.1.5192-1.el6.noarch How reproducible: 100% Steps to Reproduce: 0. Enable aviary for cumin INFO Enabled Aviary interface for job submission and control. INFO Enabled Aviary interface for query operations. 1. Cumin - submit JOB1 2. Cumin - remove JOB1 (using button on page Grid::Submission::JOB1) 3. Cumin - submit JOB1 4. Cumin - remove JOB1 5. Cumin - you are still on removed JOB1 page instead of Grid::Submission 6. Cumin - try to look around and you get 'We can't find the object...' Actual results: Message: We can't find the object you requested This often happens when a far-off agent stops or is disconnected. It may come back under a different database ID. Try navigating anew from the site root. Expected results: Go backward in user browsing history to find nearest existing widget/object. Additional info:
I have some ideas about how to do this, by tracking entry into frames during rendering and winding back up the ancestor list through enclosing frames when an error occurs. Redirects to each level should succeed at some point, or wind all the way back to the main page.
This has been improved incrementally since the initial bug report. For certain specific cases, explicit redirects are made to an enclosing scope (submission is deleted, user is returned to the submissions list for example). All other cases of missing objects should return the user to the main page with a notice that an object being displayed became unavailable. Nicer than the original bug banner. This could still be improved by tracking *which* object became unavailable. Finding an appropriate enclosing scope for an error at every level may be possible but is likely to be a lot of work.
MRG-Grid is in maintenance and only customer escalations will be considered. This issue can be reopened if a customer escalation associated with it occurs.