Skip to main content
Version: Aeon 7.0

View All Requests in Search

Every user record carries a Requests tab that lists the requests that person has placed. That embedded list is compact on purpose — it lives inside the user detail, shows the most recent requests, and is filtered to active requests by default. Most of the time that's all you need to answer "what does this person have open right now?"

View All in Search is the escape hatch for when the embedded list isn't enough. One click hands the same person's requests off to Aeon's full global search, where you get the whole history (not just active requests), the full-width filter and sort controls, pagination through every result, bulk selection, and a shareable URL. You're not running a new search — you're taking the user you already have open and re-scoping the search page to their requests.

When you'll use this
  • You're looking at a user and want their complete request history, including completed and cancelled requests — not just the active ones the tab shows by default.
  • You need the roomier search tools — stack filters, sort by a column, and work through the results full-screen.
  • You want to select several of a user's requests and act on them in bulk (route, flag, print, and so on).
  • You want a link you can paste to a colleague that opens straight to this person's requests.

The starting point: the Requests tab on a user​

  1. Open a user — search for them, or click their name from a request, appointment, or activity. The user detail opens (for example, /users/jdoe).
  2. Select the Requests tab.
  3. The tab shows a card headed Requests (N), where N is the count of requests in the current view. By default the Active toggle is on, so terminal-status requests (completed, cancelled, and the like) are hidden.
  4. From here you can filter and sort within the tab, double-click any row to open that request, or check rows to act on them in bulk.

In the card's header, to the right of the title, is the View All in Search button (an outward-arrow icon next to the label).

The tab and the search page are the same kind of list

The embedded Requests tab and the search page it sends you to use the same request rows, the same filter bar, and the same Active toggle. The difference is room: the tab is a panel inside the user record, while the search page is a full screen built for working through larger result sets.

Opening the full list​

  1. On the user's Requests tab, click View All in Search.
  2. Aeon navigates to the global search page, already switched to the Requests tab and pre-filtered to this user. The browser address becomes something like /search?username=jdoe&activeOnly=true.
  3. The results show that user's requests with the full-width filter and sort bar and the Active toggle across the top, and a virtualized list below that pages in more requests as you scroll.

Because the search page is seeded with a specific user, it stays focused on requests. A context banner appears at the top of the list — a user icon, the word USER, and the username. The result-type selector is still there, but Users and Activities are dropped from it, leaving Requests as the only choice, so you can't accidentally switch the view away to a general user or activity search. (The back arrow that normally sits to the left of the selector is hidden while the banner is up.) You're looking at one person's requests, full stop.

The search page always opens with Active on — flip it to see everything

View All in Search always arrives with the Active filter on, whatever the tab's Active toggle was set to when you clicked — that's the &activeOnly=true on the end of the address. To pull up the user's entire request history, switch the Active toggle off. Completed, cancelled, and other terminal-status requests then appear in the list.

What you can do once you're there​

The seeded search page is a normal request search, so all of its tools apply to this user's requests:

  • Filter and sort — use the filter bar to narrow by status, queue, flag, date, or any request field, and sort by a column. These stack on top of the user filter.
  • Open a request — click a row to show that request's detail beside the list. Double-click to take an edit lock and start processing it; if someone else holds the lock, a status message names them. Double-clicking also releases any edit lock you hold on a different request.
  • Select in bulk — check one or more rows to bring up the bulk-action bar and route, flag, print, or otherwise act on several of the user's requests at once.
  • Share the view — copy the browser URL. Anyone with permission who opens that link lands on the same user-filtered request list.

Permissions​

You need request-view access to see the list

The request list — both the embedded Requests tab and the full View All in Search page — requires the View level (or higher) of the Requests permission.

On the user record, a role that can't view requests gets the Requests tab replaced with a Restricted notice reading "You don't have permission to view requests," even though the rest of the user record still opens.

The search page shows no such notice. Open a /search?username=… link without request-view access and the page loads normally, but the list comes back empty with "No requests match your search" and the hint "Try a different search term." An empty result there is not proof the person has no requests — check your own permissions first.

Opening the user record in the first place requires the View level of the Users permission.