Fix: issues rendering the number tab results

[alexmigf]

closes #752

This pull request aims to enhance the performance of the number tables query by caching the data in an option. This approach ensures that the data can be reused in subsequent requests, thus reducing the load on the store.

Additionally, I've introduced a new selector that allows for limiting the query results. This is particularly useful if there's a need to retrieve, for instance, only the most recent 100 numbers.

The implementation also includes functionality to track and display the last fetch date. This feature is instrumental in determining whether there's a need for a fresh fetch of data.

The cached data is designed to be deletable, ensuring flexibility and independence across different tables.

Furthermore, I've made minor stylistic adjustments to the table, especially within the type column. For unassigned numbers, the column now displays gapped. In the context of credit-note tables, it also shows the refund order ID, enhancing clarity and information accessibility.

The functionality for number filtering and search has been preserved.

[BrunoPavlinic98]

LGTM!

[MohamadNateqi]

LGTM!

[dwalkerpriv]

The update seems to be working so far. I've noticed these documents in the drop down. Did we add these in the update?

[alexmigf]

@dwalkerpriv no, those are tables that were created in your local setup, probably on tests you made for customers, for example using code snippets.

[Terminator-Barbapapa]

I'm not sure if using AS is the best way of doing this. As the page has to be reloaded to see actual results, which is not a good UX.

[alexmigf]

I'm not sure if using AS is the best way of doing this. As the page has to be reloaded to see actual results, which is not a good UX.

What alternatives would you recommend? I believe that in large stores, waiting for page data can also be a lengthy and unpleasant experience.

[dpeyou]

@alexmigf

• I am not getting the textbox to limit the fetch.
  

• The time of the fetch is in UTC, but without indication it is UTC time. That could be a source of confusion.
  

[alexmigf]

@dpeyou

I am not getting the textbox to limit the fetch.

It has been replaced with the date interval selectors that you now see.

The time of the fetch is in UTC, but without indication it is UTC time. That could be a source of confusion.

The date_i18n function is being used without specifying the GMT timezone. In this case, it defaults to using the WordPress site's timezone settings.

[dpeyou]

From a functional standpoint, I cannot find an issue 😄

[YordanSoares]

LGTM! The query worked as expected, although I'm agree with Michael that would be nice if the result could be displayed without the need to reload the plage. That said, I also think that this could be improved later :)

[alexmigf]

@YordanSoares

...although I'm agree with Michael that would be nice if the result could be displayed without the need to reload the page.

I understand. We've handled similar implementations before, like with the Bulk Export feature. The new code uses the Action Scheduler to efficiently manage stores with a large number of orders. This method was chosen to avoid the drawbacks of using AJAX, particularly in larger stores. With AJAX, users would have to wait, and if they closed the tab, the script would stop running, leading to a poor user experience. By using the Action Scheduler, users can leave the page and come back later to view the results if the process takes too long.