duplicate a proxy model in admin on django 1.8 - django-models

I want to have a model that appear two times on django-admin, on two differents apps, because admins have access to differents apps.
On stackoverflow, it is said this should work, but the answers are a few years old.
And in my case, this doesn't work
I'm workin on django 1.8
app1/models.py
from django.db import models
class MyModel(models.Model):
thing = models.CharField(max_length=512)
app = models.CharField(max_length=512)
app1/admin.py
from django.contrib import admin
from .models import MyModel
admin.site.register(MyModel)
app2/models.py
from django.db import models
from app1.models import Model
class CustomMyModelManager(models.Manager):
def get_queryset(self):
return super(CustomMyModelManager, self).get_queryset().filter(app='app2')
class CustomMyModel(MyModel):
objects = CustomMyModelManager()
class Meta:
proxy = True
app2/admin.py
from django.contrib import admin
from .models import CustomMyModel
admin.site.register(CustomMyModel)
How is this supposed to work on django 1.8 ?

Related

Wagtail admin page for different clients

We are in the process of making a UberEat like app and will be using Django for the backend. I discovered wagtail not so long ago and was wondering if it would be possible to use it for our vendors, with each vendor having the possibility to log into Wagtail admin and having access to his/her own products, category, prices, etc. Rephrased, is there a possibility to have different admins in Wagtail that would have access to their own model instances ?
Thanks to you all
With Wagtail’s page permissions you could solve that via a "parent" page in combination with a custom "group" for each vendor. A clumsy workaround to be honest, it would require 3 steps, which could be automated. But this way you could use the full-featured Wagtail CMS in a way, in which each vendor could only see their "own" pages.
You could manage images and documents in the same way by assigning collections to vendors as well. But let’s start with the pages here.
The slug would look something like ubereatlike.app/vendorxyz/... with vendorxyz/ representing this "parent" page.
Groups can be added via the SETTINGS in the sidebar. Groups are a native part of the Django framework, see documentation. To add a new vendor, you would have to do three steps. (1) Create a parent page for this vendor. (2) Create a group for this vendor via SETTINGS --> GROUPS. Here you should check "Can access admin" and create a "native" new page permisson for the vendor’s page with all necessary permissions, like "Add", "Edit" and "Publish", for example. (3) Lastly you would have to add a new User for the vendor and choose its group as role.
To automate this I would create a custom user model, see documentation. With a post_signal for this custom user model, I would create both the parent page and the group and its permissions. This way you would add the User only and the page and the group would be generated programmatically.
# startapp vendors with models.py
from django.contrib.auth.models import AbstractUser
from django.contrib.auth.models import Group, Permission
from django.dispatch import receiver
from wagtail.models import Page
from home.models import HomePage
class VendorPage(Page):
parent_page_types = ['home.HomePage']
...
class Vendor(AbstractUser):
company_name = models.CharField(max_length=255)
# ...other fields
#receiver(models.signals.post_save, sender=Vendor)
def vendor_created(sender, instance, created, **kwargs):
if created:
# create vendor page as child of home page
home_page = HomePage.objects.first()
vendor_page = VendorPage(title=instance.company_name)
home_page.add_child(instance=vendor_page)
vendor_page.save_revision().publish() # recommended
# create group with permissions
vendor_group = Group.objects.create(...)
permission = Permisson.objects.get(...) # please look into Wagtail’s page permissons, this is just a rough draft
vendor_group.permissions.add(permission)

how to disable migration from one model of an app in django

I have an application which is using 2 database, 1 is default another is custom. So 2 of my model are using default database, else are using custom database. i do not want to migrate custom database model while running 'make migrations' command. please help it out.
You can selectively disable migration for one or more Django-Models by setting managed = False in Django Model Meta options.
from django.db import models
class LegacyModel(models.Model):
class Meta:
managed = False
It's worth mentioning that although the managed flag is set to False a migration for the model will still be created but no sql creation script.
The sql of a migration ca be check using manage.py sqlmigrate appname migration
Options.managed Defaults to True, meaning Django will create the
appropriate database tables in migrate or as part of migrations and
remove them as part of a flush management command. That is, Django
manages the database tables’ lifecycles.
If False, no database table creation or deletion operations will be
performed for this model. This is useful if the model represents an
existing table or a database view that has been created by some other
means. This is the only difference when managed=False. All other
aspects of model handling are exactly the same as normal.
From the docs
class SomeModel(models.Model):
class Meta:
managed = False

CakePHP - Routing Vs Acl/Auth

In CakePHP, when you are using Acl/Auth, do you need to have Routing.prefixes enabled to control admin access? Or should you just rely on Acl/Auth and get rid of all admin_xxx actions.
I am learning CakePHP and got confused along the way with authentication. So I started with enabling Routing.prefixes. In the course of my app development I have slowly started to migrate to Acl/Auth. I will have several groups of users such as admins, contributors, sponsors and users. I had read before that Routing.prefixes only applies when you only have 1 admin.
As an example I have the following:
<?php
class ArticlesController extends AppController{
// Helpers and Components will be included here....
$this->Auth->allow('*')
function admin_add(){
$this->layout = 'admin'
//...
}
}
If I am able to get rid of Admin Routing, should I do the following?
<?php
class ArticlesController extends AppController{
// Helpers and Components will be included here....
$this->Auth->allow('*')
// Control access to add() using ACL to only allow admin/contributors to use this action
function add(){
$this->layout = 'admin'
//...
}
}
Is this the correct approach?
Basically, the routing.prefixes is a great way for making an admin-area if you have a straight line between 'normal' users and admins and don't need to cut rights from some admins or make one user more privileged than the other.
But if you will have very different rights, groups and things you need to allow and deny between many different groups and/or users, ACL is the correct approach.
You don't need the Routing.prexfixes anymore if you use ACL and your approach would be totally correct.

GAE Django nonrel extend user model

I'm trying to extend User models with my custom model by inheriting from it like this:
class Profile(User):
...
I would like to add my custom fields to the User model but django nonrel fails with an error:
DatabaseError: Multi-table inheritance is not supported by non-relational DBs.
So how I can solve this problem? I definitely need my custom fields in User model.
Instead of overriding the User model you should create another class that holds the additional fields and bind it to User model by a 1-to-1 relationship.
from django.contrib.auth.models import User
class UserProfile(models.Model):
user = models.ForeignKey(User, unique=True)
nickname = models.CharField(max_length=50)
...
...
You Cannot do something like that in google-app-engine. If you want to have relationship in your model. You should denormailse your model in such a way that the same can be achieved in appengine's way.To know more about modeling in appengine . You can have go through the following links.
modeling in appengine
Daily profeth modeling in appengine
I wanted the request.user object to be the normal User object, but with added fields. The accepted answer doesn't allow that, as UserProfile has a member "user" instead of being a user.
This article explains how to instead inherit from User.
The steps in brief:
Make CustomUser inherit from User
Set up a custom authentication backend to return CustomUser
Have not tried it yet.

In the python version of Google App Engine, how can you override the db.Model class to save to a temp datastore rather than big table?

In Singapore, we are teaching students python using Singpath (singpath.appspot.com). In addition to letting students practice writing software in python, we would like to familiarize students with the google.appengine.ext.db API used to access big table.
What is the easiest way to modify db.Model settings in an App Engine app so that any puts or gets access a local, temporary datastore rather than writing to big table? I'm trying to do something similar to how gaeunit creates a new temporary datastore each time unit tests are run.
from google.appengine.ext import db
import logging
class MyModel(db.Model):
name = db.StringProperty()
#Configure a temp datastore to be updated instead of bigtable.
m = MyModel()
m.put() #shouldn't update bigtable
result = MyModel.all() #should fetch from temp datastore
logging.info("There were %s models saved", result.count())
You can certainly do this in the dev server by creating a new stub datastore when you want, like gaeunit. I don't think the concept really transfers to the production environment, though. A temporary datastore would have to have some kind of backing store, either the real datastore or memcache. AFAIK there's no built-in support for either.
An alternative would be to use the real datastore with some sandboxing.
You could override db.Model.kind to prefix a session ID:
#classmethod
def kind(cls):
return "%s_%s" % (SESSION_ID, cls.__name__)
This would give you basic namespacing for user-created entities.
If you have a session entity, you could populate it as the parent entity on any query that does not already specify one. This would force all of your user's entities into one entity group.
In either case, at the start of the session you could schedule a task to run later that would clean up entities that the user created.

Resources