Why

When the user doesn't input anything in the search bar and hits search, it makes an unnecessary call to the server. We can simply have it do nothing until they input.

Acceptance Criteria

1/ The search form does not send any request to the server when there is no input in the search bar.

Why

The user will need to paginate the keywords so it allows us to tab and not overload the dashboard with information

Acceptance Criteria

1. Pagniate the queries as 25 reports and 100 keywords
2. Can adjust the numbers as need be.

More info here:
https://hexdocs.pm/phoenix_pagination/readme.html

Why

In order to complete an objective.

Acceptance Criteria

1/ Write a deployment workflow for when branch is pushed onto develop, it pushes to heroku and deploys on staging.
2/ Write a deployment workflow for when branch is pushed onto main, it pushes to heroku and deploys on production.

Why

Have an scss-linter for better code quality.

Acceptance Criteria

1. Add scss-linter
2. Add it to CI

Why

For the API to be functional, it needs to handle cross-origin requests from different domains.

Acceptance Criteria

• Allow localhost to be able to connect to the Staging API

Why

Currently the search results store the Google Translate links as well. It would be better if we can omit it when saving it to the DB

Acceptance Criteria

1. Remove the Google Translate search results from the list of URLs stored.

Why

Most of the project conventions have been established over on here and here. It would be nice to update the project to match these conventions

Acceptance Criteria

1/ Update all the schemas to their individual folders such as g_searcher/search_results/schema/search_result.ex etc.
2/ Move business domain level files into their own contexts such as g_searcher/search_results.ex ➡️ g_searcher/search_results/search_results.ex

Why

Frontend for #28
Related to #9

The user will need to be directed to some results where they can see the status of their report and what results are parsed to

Acceptance Criteria

1. The dashboard should have all the user's reports rendered.
2. Each report should have its status on whether it's complete, failed, or still running.

Why

As part of the requirements, the user should be able to query for search results with SQLesk queries.

Acceptance Criteria

1. The user can use valid wildcard options for filtering search results.
2. Only selected queries will be allowed and create queries dynamically.

Why

Currently, the Error pages are basic HTML. Upgrading it to the rest of the application style would be nice

Acceptance Criteria

1. Use the styling of the base app to create an error view for 404, 500.

Why

Make an API call to fetch all the user's keywords with details similar to the dashboard

Acceptance Criteria

1. The user can fetch via API a list of keywords

Feature request

Currently, it rolls back everything when a keyword fails to save, including the report.

• We need to fail the report
• Any failed to save keywords should be taken as the CSV is malformed and should rollback all saved keywords
• It should not search for any keywords before completely saving all.

Issue

The value of the Results on Page in the Report Show Page does not match the Search Result Show Page

Expected

Show the correct value.

There are fewer values than displayed in the Results on Page column

Steps to reproduce

1. Upload CSV report
2. Navigate to Report Show Page. Observe the values
3. Navigate to one of the Search Result Show Page. Verify the values match.

Why

The user would need to be able to upload a CSV via an API call

Acceptance Criteria

1. The user can make a POST request and upload a CSV

Why

A user should be able to search across reports using a search bar.

Acceptance Criteria

1. Make queries to the table from #35
2. A user should be able to query for all information across their stored keywords.

Why

The user would need to see a link on their dashboard to an index page of all their stored keywords

Acceptance Criteria

1. Have a link on the dashboard that takes them to an index of their keywords
2. Have information such as number of results, top advertiser count, regular advertiser count, total results
3. Include parsing status on each keyword

Feature request

Modify the dashboard to list all reports with their status on completing the search.

Clicking on a report will show all the search results associated with the report.

Clicking on a search result will show details of search result and display HTML cache

Why

Users would have no prior knowledge of the advanced search features of GSearcher. Seeing a helpful tooltip that displays all the available options would provide better UX.

Acceptance Criteria

1/ Have a tooltip next to the search bar.
2/ The tool tip needs to display all the available options for advanced search filters

What to do

https://nimblehq.co/blog/hosting-providers-for-elixir-phoenix-applications
We need to set up proper CI/CD, where any merges to master when doing a release should deploy to heroku.

Acceptance Criteria

1. Successfully Deploy to Heroku
2. Have any branch merge to master automatically deploy to Heroku
3. Have versioned releases similar to our conventions

Why

The search result URLs page is bland, there isn't much information to present there other that the URLs in 3 separate URL tables.

With the Search result URL titles, we would have one extra column and better UX

Acceptance Criteria

1. Extract URLs out of the search_result schema into its own search_result_urls schema.
2. One search result would have many search result URLs.
3. Redesign the search_result URLs page to include the extra column.
4. In the search worker, we need to save this extra information by targeting the specific class and fetching the title

Why

Update the landing page to tailwind, and create base styles so we can have an easier time developing in the long run

Acceptance Criteria

1. Update landing page to use tailwind
2. Update the dashboard page to use tailwind
3. Create some base styling for buttons, headings, and links for consistency across the site.

Why

Currently, the form is taking up too much space on the dashboard, having more space is nice to have.

Acceptance Criteria

1. Make the upload report form hidden from view until the user clicks the upload button.
2. Move the upload button to the right of the report index table.

Why

A user should be able to search across reports using a search bar.

Acceptance Criteria

1. Have the dashboard pages display a search bar
2. Typing a query and searching should take them to a page with the search results

Why

On the dashboard, there will be an index of all the user's reports,
The user should be able to click on one of these reports to get a list of all the associated keywords and whether they're parsed or not.

Acceptance Criteria

1. Display an index of keywords associated to the report
2. Display a status depending on whether the keyword is searched or not.
3. Clicking on a completed keyword should take the user to the search result with it's details and HTML view of the search result.

Why

Just better UX overall instead of refreshing the page constantly, as well as a chance to take a deeper look into Phoenix LiveView

Acceptance Criteria

1. Integrate Phoenix LiveView into project
2. Convert dashboard route to a Live route.
3. Create a channel for report updates so we can broadcast updates directly from the worker.

Why

The dashboard is going to contain the report index, so we would need to have a create report button that when clicked,
will display the create report form.

Acceptance Criteria

1. Add a button to create the report that when clicked will display the create report form
2. Animate with fade down / fade up when toggling the form.

Why

Currently, the search_result index in the API returns all the search results associated with the user. We need to add pagination so that we can query a selection of data, and will have more space to introduce the "relationship" and "included" attributes as part of the JSONAPI spec.

Acceptance Criteria

1/ Introduce pagination to the API
2/ Add the "relationship" and "included" attribute to the search result index.

Why

Related to #9
The user will need to be directed to some results where they can see the status of their report and what results are parsed to

Acceptance Criteria

1. The dashboard should have all the user's reports rendered.
2. Each report should have its status on whether it's complete, failed, or still running.

Why

The current README is using the default generated by Phoenix. We'd rather have a custom README.

Acceptance Criteria

• Update the README to be a bit more stylish and relevant.

Why

Similar to the searching feature on the dashboard

Acceptance Criteria

1. The user is able to make an API call to search for keywords

Why

We need to encode an access token that we can use to represent the session. This token should time out after a period of time.

Acceptance Criteria

1. Encode the user session into an access token using Guardian.
2. Have the token time out after 1 day.