upgrading from 1.11 and ran into builtin permission clash

[Sheila Miguez]

Hi all,

I'm upgrading from Django 1.11 step by step and am at the stage where I'm upgrading to 2.2. I've run into a problem. I have a custom permission called view_[modelname] that I created in 1.11, and that permission clashes with the default view permission that was added in 2.1.

hardware.InventoryChangeLog: (auth.E005) The permission codenamed 'view_inventorychangelog' clashes with a builtin permission for model 'hardware.InventoryChangeLog'.

What do I do about this? Clearly I should remove the permission I created. How do I deal with the migration? Should I remove the permission while I run the app as Django 1.11 before moving on to a 2.2 environment?

--

Sheila Miguez

she...@pobox.com

[Joel Goldstick]

Sorry, I can't answer your question. But, I am wondering why you are
upgrading to a very out of date version of Django that is no longer
supported. I think 3.2 is the oldest supported version. Why not
upgrade to 4?

--
Joel Goldstick

[Michael Manfre]

> What do I do about this? Clearly I should remove the permission I created. How do I deal with the migration? Should I remove the permission while I run the app as Django 1.11 before moving on to a 2.2 environment? 

You could rename the current view_inventorychangelog record with a data migration to avoid the constraint, upgrade to 2.2, and then move any references to the old DB record to the new using a data migration.

> Sorry, I can't answer your question. But, I am wondering why you are

> upgrading to a very out of date version of Django that is no longer
> supported. I think 3.2 is the oldest supported version. Why not

> upgrade to 4?

The options for uplifting severely out of date projects are to either step-by-step migrate through older versions, or rewrite in the target version.

Cheers,

Michael Manfre

[Jason]

Joel Goldstick, would definitely not recommend doing an all in one update.  That'd be like going from windows XP to 10 in one go.  For personal projects, you could do it, but would side-eye any professional who suggested doing this with a company or workplace project.

https://docs.djangoproject.com/en/4.0/releases/2.1/#model-view-permission is liekly the permission being hit.  OP, would it be possible for you to rename the original permission name in a migration in 1.11, and then move forward with the migration?

[Sheila Miguez]

I could try that.

So far I've made a toy project to reproduce the problem and made a migration in 1.11 to remove the permission. When I started it up in 2.2 it suddenly said I had unapplied migrations in admin and auth.

I don't know if renaming would have the same effect. I'll try it.

[Jefri Simorangkir]

Deal

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/cdfce75a-6bb1-4d1b-81a5-a03785cdddb4n%40googlegroups.com.

[Steven Mapes]

What I'd advise is to upgrade to point just before it breaks, then update the permission to use a different name, then upgraded to 2.2 avoiding the name clash. Once upgraded then edit the permission to grant the permission to the users who need that permission based on your now renamed custom permission. Then remove your custom permission.

I'd do it this way so that you don't loose data on which users had that permission in the first place.  Or rename the permission at the start then upgrade.

For those saying "why not upgrade to 4" there are many good reasons why you may not/ can not, use Django 4 at the moment such as reliance on unsupported 3rd party libs or, more commonly, regressions and lack of LTS.  It's quite common for companies/projects that need stability to only upgrade from LTS version to LTS version as they can't risk the regressions that often happen in between

[Atsin Yapi]

Hello 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ef92d745-6cb1-41c2-9285-f4c0722759a3n%40googlegroups.com.