| | 247 | |
| | 248 | == Solution 2e: `MYAPP_USER_MODEL` setting (b) == |
| | 249 | |
| | 250 | A combination of solution 2b and 2d. Every model is pluggable and each app has its own `USER_MODEL` setting. |
| | 251 | |
| | 252 | === Implementation === |
| | 253 | |
| | 254 | `django.contrib.admin` can introduce an `ADMIN_USER_MODEL` setting which defaults to `"auth.user"`. |
| | 255 | |
| | 256 | {{{ |
| | 257 | user = models.ForeignKey(settings.ADMIN_USER_MODEL) |
| | 258 | }}} |
| | 259 | |
| | 260 | === Advantages === |
| | 261 | |
| | 262 | * support multiple user models |
| | 263 | * Existing projects require no migration. the same as solution 2/2a. |
| | 264 | * Unlike solution 2a, change is not required for existing apps, if they do not use a different user model. |
| | 265 | * Unrelated and third-party apps can indicate that they depend on various orthogonal mixins. the same as solution 2a. |
| | 266 | |
| | 267 | === Problems === |
| | 268 | |
| | 269 | same as solution 2b, and |
| | 270 | |
| | 271 | * As with Solution 2, prone to unpredictable problems if `MYAPP_USER_MODEL` is modified after the initial syncdb. |