Comment 11 for bug 1517137

Jason Boyer (jboyer) wrote :

I had a couple thoughts about the upgrade script. (I wanted to get this out asap and so didn't *implement* any of them, but I did have them, heh.)

What came to mind first is that if you added a permission manually that you knew to be missing you could expect to have to deal with conflicts when that fix comes down the line. That's admittedly lazy thinking and not very friendly to less experienced admins. So something else should be done instead.

Which leaves these two options:

In the upgrade create individual insert statements, don't use a transaction, and \echo that it's ok if these things fail. There have been (parts of?) scripts that have done that in the past. This is the simple/safe way to do it although personally I like for code to be able to depend on "system" things being in predictable places so this isn't my preference. (Perms aren't quite as important as things like billing reasons in this regard, but given my recent issues with coded value maps I have become much more picky about such things.)

Or, use a DO block to rename currently conflicting perms with ids > 1000, insert the id < 1000 versions, and replace any mappings under permission.* to use the new perms instead of the old and then remove the local ones. This obviously requires more testing and has more potential for issues than the above, but is entirely DOable (heh).

So what say ye: let the perms fall where they may or tidy up the place?