3.9 KiB
opportunity-exploration Specification
Purpose
Let users explore Oracle opportunities within a fiscal Reference using consistent filters, totals and sortable tabular data.
Requirements
Requirement: Queries use the user's default saved search
Opportunity queries SHALL resolve the unique saved search marked isDefault=true and use its savedSearchNumber in copiedFrom for every page. Missing or ambiguous default searches SHALL prevent a dependent opportunity query.
Scenario: Valid default search
- WHEN saved searches return exactly one valid default
- THEN the opportunity payload uses
queries/<savedSearchNumber>and reuses it throughout pagination
Scenario: No valid default
- WHEN no unique default saved search is returned
- THEN the extension reports the failure instead of using a hard-coded saved-search identifier
Requirement: Opportunities display before background enrichment
The extension SHALL collect the opportunity result pages before displaying the ready list, then start Service Request and product enrichment without waiting for them to finish. Responses from an obsolete Reference request SHALL not replace the active result.
Scenario: SR remains pending
- WHEN opportunity pagination completes and Service Request loading remains pending
- THEN the opportunity table is already usable
Scenario: Reference changes during loading
- WHEN an older query completes after a newer Reference query has started
- THEN the older result does not overwrite the active view
Requirement: Reference uses Oracle fiscal periods
The selected Reference SHALL determine the query date range using a June-through-May fiscal year. Opportunity type selections SHALL also constrain the query; an empty type selection SHALL show an explanatory empty state without sending an opportunity query.
Scenario: Fiscal first quarter
- WHEN Reference resolves to the first fiscal quarter
- THEN the selected period covers June through August with the next quarter boundary excluded
Requirement: Filters are coordinated across views
Overview and Calendar SHALL share search, Customer, Owner, Status, Stage, eligible SR/Action filters and Booking/Workload filters. Customer options SHALL narrow by selected Owners and Owner options by selected Customers without additional API calls.
Scenario: Customer narrows owner choices
- WHEN a customer associated with two owners is selected
- THEN the Owner choices contain the corresponding owners and widening the customer selection restores applicable choices
Scenario: All-selected item is clicked
- WHEN the user clicks an item while all choices in its multiselect or filter-badge group are selected
- THEN only that item remains selected and subsequent clicks can add other choices
Scenario: Booking isolation
- WHEN both Booking and Workload are selected and Booking is clicked
- THEN only Booking opportunities remain visible in both views
Requirement: Overview preserves table meaning and ordering
Overview SHALL restore its last sort column and direction, display customer PartyName, label win probability Prob., and give Name and Customer greater width priority. Monetary cells and their headers SHALL align right; other headers SHALL align left.
Scenario: Overview reopens
- WHEN the user reopens Overview after selecting a descending Amount sort
- THEN that ordering is restored and the displayed amount values determine the order
Requirement: Indicators reflect the filtered opportunities
The opportunity count and stage amounts SHALL follow the active filters without issuing additional queries solely to calculate the displayed indicators.
Scenario: Local filter changes
- WHEN the user narrows the loaded list using a Customer filter
- THEN the count and stage indicators update with the filtered opportunities