Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Est:3] [Prestashop] Update on save - multi-indice #230

Closed
sofia-doofinder opened this issue Jul 30, 2024 · 2 comments · Fixed by #233
Closed

[Est:3] [Prestashop] Update on save - multi-indice #230

sofia-doofinder opened this issue Jul 30, 2024 · 2 comments · Fixed by #233

Comments

@sofia-doofinder
Copy link
Contributor

Notion: https://witty-pelican-a6c.notion.site/Update-on-save-multi-indice-65e4bd9c37a64231845e2390d27f3ee5?pvs=4

@sofia-doofinder sofia-doofinder changed the title [Prestashop] Update on save - multi-indice [Est:3] [Prestashop] Update on save - multi-indice Jul 30, 2024
@eduardogomez97
Copy link
Member

After doing the technical consultation with @sofia-doofinder it has been decided that since at that level the platform has the store_id and it makes sense to have the logic, to know if the search_engine is valid in the update on save, in dooplugins. The plugin is responsible for making a request to the endpoint created by sending the store_id and receive a response if it is valid or not.

If it is valid, it will proceed as usual, if not, the update on save will be marked as deactivated.

The part of doomanager of the wizard of indexes after talking with @IgnacioPursalsZ has been resolved that right now it does not make sense. Since the way it works now the message would be always shown. This is because in the update on save we check the feed_type that is in datasources.options and this at the time of creating a manual index does not exist. The update on save (to maintain compatibility with old clients) if it detects that a datasource.options does not have this value, it interprets it as “product” (this was done for backward compatibility).

This generates the following conflict for the wizard. If we want to make the same detection as in the update on save it will always recognize that it is not suitable (since the manually created ones do not have that field). The case of making that at that point it is not interpreted as product would never show the message but it would give the conflict later.

So it has been reached that at the moment it does not make sense to make any change in the wizard.

@eduardogomez97
Copy link
Member

Ya está publicada la nueva versión y funcionando!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants