search

shacker / django-todo

A multi-user, multi-group todo/ticketing system for Django projects. Includes CSV import and integrated mail tracking.
http://django-todo.org
BSD 3-Clause "New" or "Revised" License
819 stars 285 forks source link

search in comments as well #45

Open ezzra opened 5 years ago

ezzra commented 5 years ago

the search function does not find words within comments, that could be helpful when implemented

shacker commented 5 years ago

Not a bad idea. With larger databases with millions of comments, this could make search expensive (slow). We might want to make it a settings option for that reason. Also, it means searching two different models rather than one, so it's a more complex proposition, but I can see the use case. I'm going to let this one simmer for a bit, unless someone contributes code for it.

bittner commented 5 years ago

You may want to consider relying on Postgres capabilities. @pauloxnet had a few talks about this in the past (see related blog post).

shacker commented 5 years ago

Based on the dust-up that occurred in #52, it's clear we have MySQL users, and we can't use anything postgres-specific unless the project makes a decision only to support Postgres. Part of me would love to do that, but I think the decision to go postres-only is up to individual projects and shouldn't be enforced by 3rd-party apps like this one. As long as Django supports MySQL, django-todo should support it too.

Still, this should not be too difficult to handle with traditional methods.

dalinxz commented 4 years ago

Based on the dust-up that occurred in #52, it's clear we have MySQL users, and we can't use anything postgres-specific unless the project makes a decision only to support Postgres. Part of me would love to do that, but I think the decision to go postres-only is up to individual projects and shouldn't be enforced by 3rd-party apps like this one. As long as Django supports MySQL, django-todo should support it too.

Still, this should not be too difficult to handle with traditional methods.

My app is running Postgresql and it worked without a flaw, I did have to comment out the fieldsets in my CustomUser admin.py file prior to running the migration, otherwise I was getting a duplicate field in fieldset error. After commenting it out, it migrated perfectly, then I was able to uncomment the lines I commented and get back to business.

dalinxz commented 4 years ago

Based on the dust-up that occurred in #52, it's clear we have MySQL users, and we can't use anything postgres-specific unless the project makes a decision only to support Postgres. Part of me would love to do that, but I think the decision to go postres-only is up to individual projects and shouldn't be enforced by 3rd-party apps like this one. As long as Django supports MySQL, django-todo should support it too. Still, this should not be too difficult to handle with traditional methods.

My app is running Postgresql and it worked without a flaw, I did have to comment out the fieldsets in my CustomUser admin.py file prior to running the migration, otherwise I was getting a duplicate field in fieldset error. After commenting it out, it migrated perfectly, then I was able to uncomment the lines I commented and get back to business.

I was having this same issue on constantly having to uncomment the lines in the CustomUser admin.py file, I was able to address it by removing the two fieldsets that were already included on the built-in or allauth model, in my case it was username and email, removing those from the additional fieldsets removed Django from constantly piping about duplicate fieldsets. hope it helps..