resolve migration issues

[mhl]

There are various fields in the committed core/models.py that appear not to have had migrations generated for them:

 ./manage.py schemamigration core --auto
  ~ Changed field entered on core.InformationSource
  ~ Changed field can_be_featured on core.Person
  ~ Changed field requires_place on core.PositionTitle
  ? The field 'PlaceKind.plural_name' does not have a default specified, yet is NOT NULL.
  ? Since you are adding or removing this field, you MUST specify a default
  ? value to use for existing rows. Would you like to:
  ?  1. Quit now, and add a default to the field in models.py
  ?  2. Specify a one-off value to use for existing columns now
  ? Please select a choice: 

At least the PlaceKind.plural_name one is a case where a bad merge caused it not to appear in the models field of migrations 0032 and 0033 even though it was introduced in 0031. (That can be fixed up by updating the models field in the latter two from 0031.)

The others mentioned above still need to be investigated.

There are some other migration oddities that I've spotted - for example:

1. It seems that disabled_comment appears in the models field of 0031, but wasn't introduced in any migration. (This was a from a migration in the scorecards application, not core.)
2. The migrations contain hardcoded datetimes in the updated and created fields.

[mhl]

Number 2 is dealt with (from this point on, anyway) by 11a7d0f

[mhl]

The remaining issues are these three:

~ Changed field entered on core.InformationSource ~ Changed field can_be_featured on core.Person ~ Changed field requires_place on core.PositionTitle

For all of these, South is trying to add blank=True in its automatically generated migration.

For example, the field can_be_featured of Person is curious - it doesn't appear to have changed in any of the model fields of migrations since it was added:

$ grep can_be_featured core/migrations/*.py
core/migrations/0030_[..]:        # Adding field 'Person.can_be_featured'
core/migrations/0030_[..]:        db.add_column('core_person', 'can_be_featured', self.gf('django.db.models.fields.BooleanField')(default=False), keep_default=False)
core/migrations/0030_[..]:        # Deleting field 'Person.can_be_featured'
core/migrations/0030_[..]:        db.delete_column('core_person', 'can_be_featured')
core/migrations/0030_[..]:            'can_be_featured': ('django.db.models.fields.BooleanField', [], {'default': 'False'}),
core/migrations/0031_[..]:            'can_be_featured': ('django.db.models.fields.BooleanField', [], {'default': 'False'}),
core/migrations/0032_[..]:            'can_be_featured': ('django.db.models.fields.BooleanField', [], {'default': 'False'}),
core/migrations/0033_[..]:            'can_be_featured': ('django.db.models.fields.BooleanField', [], {'default': 'False'}),

... and it hasn't been changed in models.py. However, in the generated migration, it ends up as:

'can_be_featured': ('django.db.models.fields.BooleanField', [], {'default': 'False', 'blank': 'True'}),

... and the forward action of the generated migration is trying to do:

# Changing field 'Person.can_be_featured'
db.alter_column('core_person', 'can_be_featured', self.gf('django.db.models.fields.BooleanField')(blank=True))

[mhl]

The case of entered in core.InformationSource is also interesting. In the representation of the models in migrations 0004 up to 0027, entered is {'default': 'False', 'blank': 'True'}, but in 0028 to 0033 it is {'default': 'False'}, but the definition of entered in models.py hasn't changed since the introduction of the InformationSource model. (Checked with git log --follow -Gentered -p core/models.py.)