Custom Query (27017 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (16 - 18 of 27017)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#29124 duplicate Generated migration orders RemoveField and AlterUniqueTogether incorrectly, causing FieldDoesNotExist nobody Ed Morley
Description

Removing a field and its corresponding unique_together entry results in a FieldDoesNotExist exception when creating/applying the migration.

This affects Django master + v1.11.10, and both the SQLite and MySQL backends (others not tested).

(See also #29123 which also only reproduces when unique_together is used)

STR:

  1. Git clone https://github.com/edmorley/django-migration-remove-field-testcase
  2. pip install https://github.com/django/django/archive/master.zip
  3. ./manage.py migrate
  4. cp testapp/models_new.py testapp/models.py
  5. ./manage.py makemigrations --name broken_migration
  6. ./manage.py migrate

Expected:

New migration is created/applied successfully, which converts from the original model to the new model.

Actual:

The new 0002_broken_migration.py migration incorrectly lists the RemoveField operation before the AlterUniqueTogether operation...

    operations = [
        migrations.RemoveField(
            model_name='push',
            name='foo',
        ),
        migrations.AlterUniqueTogether(
            name='push',
            unique_together={('repository', 'revision')},
        ),
    ]

Which results in an exception at step 6...

$ ./manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions, testapp
Running migrations:
  Applying testapp.0002_broken_migration...Traceback (most recent call last):
  File ".../site-packages/django/db/models/options.py", line 564, in get_field
    return self.fields_map[field_name]
KeyError: 'foo'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  ...
  File ".../site-packages/django/db/backends/base/schema.py", line 286, in create_model
    columns = [model._meta.get_field(field).column for field in fields]
  File ".../site-packages/django/db/backends/base/schema.py", line 286, in <listcomp>
    columns = [model._meta.get_field(field).column for field in fields]
  File ".../site-packages/django/db/models/options.py", line 566, in get_field
    raise FieldDoesNotExist("%s has no field named '%s'" % (self.object_name, field_name))
django.core.exceptions.FieldDoesNotExist: Push has no field named 'foo'

Additional notes:

  • If the ('repository', 'revision') entry in unique_together is omitted from both the original and new models, then the bug does not occur.
  • This affects both the SQLite backend and the MySQL backend (others not tested).
  • At time of testing, django master was at revision 6d794fb76212bb8a62fe2cd97cff173054e1c626.
  • The above was using Python 3.6.2.
#29121 invalid Admin ChangeList trims off multi-valued query parameters nobody Jeffrey Bian
Description

In contrib.admin.views.main module - ChangeList class constructor, when populating self.params with GET query parameters, it converts it into a single valued dict. E.g., for customized parameters like "tag=1&tag=10&tag=3", only one value will be preserved.

https://github.com/django/django/blob/master/django/contrib/admin/views/main.py#L66

Suggested fix:

Instead of calling request.GET.items(), usse request.GET.lists() so to preserve all values. Thus the line reads:

self.params = dict(request.GET.lists())

This will flatten the dict while making the multiple values of a key into a list.

Patch below in attachment.

Regards,

#29119 invalid Request for discussion / maybe features nobody Stephan Doliov
Description

I would like to do some retooling of the django.contrib.auth app, in particular the user model and its swapability. I hope to generate some discussion with this ticket, it would not, IMO, make sense to consider this a single feature request. Rather, if there is support for my thoughts, we can figure out how to break up the work to make it go.

My overall goals are: Kill both the conception of is_superuser and is_staff as direct attributes of User Kill the last_login as a stateless field in the default User model Kill the username field (using email as primary identifer is fine for my purposes and I don't like towing around deadspace in the backing database) To only associate information with an authenticated (or authenticable) user in a stateless way in which it is absolutely necessary that would be identifier (e.g. email) password and I see the convenience of is_active flag but not sure if it is necessary (it could be derived by no permissions be associated with a given user)

then a login history table could take place of the the last login field (or a more generic event table, where one of the events was a 'user_login' is_staff and is_superuser should be up to the app builder to decide. maybe there are some default permissions that are the equivalent, but those are far more things that are like roles (or Groups in django speak) than a user attribute.

Thoughts?

Face value, this is easy enough, I can create a swappable user model (following the pattern of AbstractBaseUser, AbstractUser and User) and have tinker with the last_login, is_superuser and username fields as desired.

But seeing that auth and admin apps are somewhat tightly coupled, it also means I have to set the last_login, is_superuser, and last_login attributes as properties in my concrete user class (and add getters/setters as desired, or just return False or None respectively).

So I do that and then the rubber hits the road because of: auth/apps.py

from django.apps import AppConfig
from django.core import checks
from django.db.models.signals import post_migrate
from django.utils.translation import gettext_lazy as _

from . import get_user_model
from .checks import check_models_permissions, check_user_model
from .management import create_permissions
from .signals import user_logged_in


class AuthConfig(AppConfig):
    name = 'auth'
    label = 'auth'
    verbose_name = _("Authentication and Authorization")

    def ready(self):
        post_migrate.connect(
            create_permissions,
            dispatch_uid="auth.management.create_permissions"
        )
        if hasattr(get_user_model(), 'last_login'):
            from .models import update_last_login
            user_logged_in.connect(update_last_login, dispatch_uid='update_last_login')
        checks.register(check_user_model, checks.Tags.models)
        checks.register(check_models_permissions, checks.Tags.models)

and the update_last_login method is defined in auth.models as

def update_last_login(sender, user, **kwargs):
    """
    A signal receiver which updates the last_login date for
    the user logging in.
    """
    user.last_login = timezone.now()
    user.save(update_fields=['last_login'])

This of course generates a failure because the last_login field no longer exists in my User Model (I prefer to keep track of the entire history of login events elsewhere, as my app has a need to be able to provide the audit trail of all logins by a user).

As best I understand it, I cannot just override the AuthConfig definition -- that is, I can wholesale copy the auth app into my app and then update the config, removing or modifying the offending line. But that seems ugly to me.

It seems to me that if User models are truly swappable, then I wouldn't have to carry the last_login field and I wouldn't have to worry about django.contrib.auth hardcoding it as if it always existed.

A first order fix for this would be to test if the current user model has a last_login model field and only issuing the save() call with the last_login attribute if it exists.

Is_staff and is_superuser are not beset by the same problem, it is just that they are coupled into the logic of admin. that would be in: django/contrib/admin/forms.py django/contrib/admin/sites.py django/contrib/admin/views/decorators.py

As the auth and admin apps currently are (useful and robust for sure) I wouldn't want to undo this, but I am wondering if the very way in which Permissions are done in django should also be swappable?

Thanks for reading this long post, I look forward to some feedback.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.
Back to Top