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

Django 1.10 warning get_field_by_name #55

Open
bschellekens opened this issue Jun 19, 2016 · 6 comments
Open

Django 1.10 warning get_field_by_name #55

bschellekens opened this issue Jun 19, 2016 · 6 comments

Comments

@bschellekens
Copy link

Hi,
With lots of pleasure I'm using fsm-admin, great stuff! I notice that there is a minor warning when moving to 1.10. Any plans to adjust the code?

fsm_admin/mixins.py:78: RemovedInDjango110Warning: 'get_field_by_name is an unofficial API that has been deprecated. You may be able to replace it with 'get_field()' with: return self.model._meta.get_field_by_name(fsm_field_name)[0]

@bschellekens bschellekens changed the title Django 1.10 warnings Django 1.10 warning get_field_by_name Jun 19, 2016
@bschellekens
Copy link
Author

This occurs in two area's of the code in the module mixins.py

  1. fms_field_instance (code line 78).
  2. _get_possible_transitions (code line 224)

Solution: replace get_fields_by_name(field)[0] by get_fields(field)

Shall I post a pull request or would you rather do this?

@Nagyman
Copy link
Contributor

Nagyman commented Jun 20, 2016

@bschellekens we're happy to review and accept pull requests! Does this removal affect support for previous versions of Django?

@gigelu
Copy link

gigelu commented Aug 8, 2016

The new _meta API was introduced in 1.8 - https://docs.djangoproject.com/en/1.8/ref/models/meta/, so it will break older versions.

Also, the new method is get_field, not get_fields.

grzegorzbialy added a commit to elcodo/django-fsm-admin that referenced this issue Aug 22, 2016
@decentral1se
Copy link
Contributor

With the release of Django 1.10, this is now breaking peoples code.

I suggest we start with #59, so we know what is breaking.

This package needs a compatibility plan :)

@randy-jimenez
Copy link

+1 Didn't see this issue before we upgraded to 1.10. Ended up monkey-patching the missing methods back in to get things working again.

@clovis1122
Copy link

Still happening.

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

No branches or pull requests

6 participants