Extensions List: Wrong results filtering tags #128

New Issue

Pablo Vazquez · 2024-05-15T16:56:57+02:00

Pablo Vazquez commented

2024-05-15 16:56:57 +02:00

Filtering extensions by tag seems to check for tags in all versions of an extension, not just the most recent.

For example, the extension Gold Pro version 1.0.0 had tags Animation, Sequencer. While the latest version 1.0.1 has the tag Dark.

When filtering for the tag Sequencer, Gold Pro shows up:

Filtering extensions by tag seems to check for tags in **all** versions of an extension, not just the most recent. For example, the extension Gold Pro version [1.0.0](https://extensions.blender.org/themes/gold-pro-theme/versions/#v100) had tags `Animation`, `Sequencer`. While the latest version [1.0.1](https://extensions.blender.org/themes/gold-pro-theme/versions/#v101) has the tag `Dark`. When filtering for the tag [Sequencer](https://extensions.blender.org/tag/sequencer/), Gold Pro shows up: ![wrong tags](/attachments/4e0d5df5-311c-46da-b576-037a41ee3903)

image.png

273 KiB

Pablo Vazquez added the

Type

Report

label 2024-05-15 16:56:57 +02:00

Oleg-Komarov commented

2024-05-16 17:28:52 +02:00

It's possible to fix this if we indeed limit all searches only to the latest version.
We would need to update the data model by either making extension.latest_version a materialized field (currently it's computed by fetching all versions and sorting by date to pick the latest), or by adding version.is_latest flag. In both cases this data needs to be updated every time a version gets listed or de-listed.

I can also imagine a different use case when a user actually wants to search through all the versions, e.g. it can be possible that an older version had a legitimate tag, and now we would expect to find it. In this case I would also expect a different results page presentation: making it clear that I found a particular version of an extension. This also probably suggests a clear UI difference for an entry point of such search.

If this second use case sounds too artificial, I'd argue that we should move tags from manifest/version to the extension level.
What was the reason to put them at the version level? Why not edit them at the same time as the description?

It's possible to fix this if we indeed limit all searches only to the latest version. We would need to update the data model by either making `extension.latest_version` a materialized field (currently it's computed by fetching all versions and sorting by date to pick the latest), or by adding `version.is_latest` flag. In both cases this data needs to be updated every time a version gets listed or de-listed. I can also imagine a different use case when a user actually wants to search through all the versions, e.g. it can be possible that an older version had a legitimate tag, and now we would expect to find it. In this case I would also expect a different results page presentation: making it clear that I found a particular version of an extension. This also probably suggests a clear UI difference for an entry point of such search. If this second use case sounds too artificial, I'd argue that we should move tags from manifest/version to the extension level. What was the reason to put them at the version level? Why not edit them at the same time as the description?

Pablo Vazquez commented

2024-05-16 17:55:47 +02:00

What was the reason to put them at the version level? Why not edit them at the same time as the description?

Mainly so they are available inside Blender. However, we do collect online info from within Blender so we could do that too. I'd simplify updating existing extensions when new tags get added indeed.

@dfelinto can maybe expand on this.

> What was the reason to put them at the version level? Why not edit them at the same time as the description? Mainly so they are available inside Blender. However, we do collect online info from within Blender so we could do that too. I'd simplify updating existing extensions when new tags get added indeed. @dfelinto can maybe expand on this.

Oleg-Komarov commented

2024-05-16 18:20:12 +02:00

Yes, this makes it similar to #111

Should we move the tags to the extension level then, treating them exactly like other metadata fields that are taken from the manifest?
This would mean replacing the full set when a new version that specifies tags is uploaded.

Yes, this makes it similar to https://projects.blender.org/infrastructure/extensions-website/issues/111 Should we move the tags to the extension level then, treating them exactly like other metadata fields that are taken from the manifest? This would mean replacing the full set when a new version that specifies tags is uploaded.

Dalai Felinto pinned this 2024-05-16 23:54:39 +02:00

Oleg-Komarov commented

2024-05-23 15:47:41 +02:00

@dfelinto do you have any objections or do you support the change suggested above: make tags a part of extension metadata instead of version metadata?