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

tag_kwargs are not taken into account when TAGGIT_CASE_INSENSITIVE is True #859

Closed
dennisv opened this issue Jun 22, 2023 · 0 comments · Fixed by #860
Closed

tag_kwargs are not taken into account when TAGGIT_CASE_INSENSITIVE is True #859

dennisv opened this issue Jun 22, 2023 · 0 comments · Fixed by #860

Comments

@dennisv
Copy link
Contributor

dennisv commented Jun 22, 2023

tag_kwargs are not taken into account when case insensitivity is turned on, while they are when it is off.
For cases like #809 that would result in already existing tags, with the same name, from other users/tenants being used instead of creating a new one.

When case insensitivity is turned off, this will work as expected as the tag_kwargs are used in the filter to check for existing tags.

In _TaggableManager._to_tag_model_instances:

if case_insensitive:
# Some databases can do case-insensitive comparison with IN, which
# would be faster, but we can't rely on it or easily detect it.
existing = []
tags_to_create = []
for name in str_tags:
try:
tag = manager.get(name__iexact=name)
existing.append(tag)
except self.through.tag_model().DoesNotExist:
tags_to_create.append(name)
else:
# If str_tags has 0 elements Django actually optimizes that to not
# do a query. Malcolm is very smart.
existing = manager.filter(name__in=str_tags, **tag_kwargs)
tags_to_create = str_tags - {t.name for t in existing}

If I change the get call on line 229 to get(name__iexact==name, **tag_kwargs) it works the same for both cases.

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

Successfully merging a pull request may close this issue.

1 participant