2017-08-24 13 views
6

मुझे syncdb और makemigrations से अवगत है, लेकिन हम उत्पादन वातावरण में ऐसा करने के लिए प्रतिबंधित हैं।Django व्यवस्थापक - सुपरसियर के लिए दृश्यमान मॉडल, कर्मचारी उपयोगकर्ता

हमने हाल ही में उत्पादन पर बनाए गए कुछ टेबल बनाए थे। जैसा कि अपेक्षित था, किसी भी उपयोगकर्ता के लिए व्यवस्थापक पर टेबल दिखाई नहीं दे रहे थे।
पोस्ट कि, हम उत्पादन एसक्यूएल पर मैन्युअल रूप से निष्पादित 2 प्रश्नों नीचे था (मैं अपने स्थानीय पर स्थानांतरण भाग गया और कच्चे एसक्यूएल लाने के लिए show create table क्वेरी किया था)

django_content_type

INSERT INTO django_content_type(name, app_label, model) 
values ('linked_urls',"urls", 'linked_urls'); 

auth_permission

INSERT INTO auth_permission (name, content_type_id, codename) 
values 
('Can add linked_urls Table', (SELECT id FROM django_content_type where model='linked_urls' limit 1) ,'add_linked_urls'), 
('Can change linked_urls Table', (SELECT id FROM django_content_type where model='linked_urls' limit 1) ,'change_linked_urls'), 
('Can delete linked_urls Table', (SELECT id FROM django_content_type where model='linked_urls' limit 1) ,'delete_linked_urls'); 

अब थाई एस मॉडल सुपर-यूजर के तहत दिखाई देता है और कर्मचारियों के उपयोगकर्ताओं को भी पहुंच प्रदान करने में सक्षम है, लेकिन स्टाफ उपयोगकर्ता इसे देख नहीं सकते हैं।
क्या कोई टेबल प्रविष्टि है जिसमें इसे दर्ज करने की आवश्यकता है?

या कोई syncdb, माइग्रेशन बिना इस समस्या को हल करने के लिए कोई दूसरा रास्ता नहीं है?

+0

_staff_ उपयोगकर्ताओं के लिए एक समूह हो सकता है। क्या आपने इसे अनुमति दी थी? –

+0

हां, भी, बहुत सारे स्टैंडअलोन कर्मचारी उपयोगकर्ता किसी भी समूह से संबंधित नहीं हैं! – NoobEditor

+0

फिर मैं उपयोगकर्ता-समूह 'कर्मचारी' बनाने और सभी कर्मचारियों के उपयोगकर्ताओं को असाइन करने का सुझाव दूंगा। मैं उसमें नहीं हूं, लेकिन असाइनमेंट को एक एसक्यूएल कमांड द्वारा भी संभालना संभव होना चाहिए। –

उत्तर

1

तो, अंत में मैं एक solution.I Django पर डिबगिंग के बहुत कुछ किया और apparanetly (django.contrib.auth.backends पर ) समारोह नीचे था अनुमतियाँ प्रदान करने के लिए काम करता है।

def _get_permissions(self, user_obj, obj, from_name): 
    """ 
    Returns the permissions of `user_obj` from `from_name`. `from_name` can 
    be either "group" or "user" to return permissions from 
    `_get_group_permissions` or `_get_user_permissions` respectively. 
    """ 
    if not user_obj.is_active or user_obj.is_anonymous() or obj is not None: 
     return set() 

    perm_cache_name = '_%s_perm_cache' % from_name 
    if not hasattr(user_obj, perm_cache_name): 
     if user_obj.is_superuser: 
      perms = Permission.objects.all() 
     else: 
      perms = getattr(self, '_get_%s_permissions' % from_name)(user_obj) 
     perms = perms.values_list('content_type__app_label', 'codename').order_by() 
     setattr(user_obj, perm_cache_name, set("%s.%s" % (ct, name) for ct, name in perms)) 
    return getattr(user_obj, perm_cache_name) 

तो समस्या क्या थी?

INSERT INTO django_content_type(name, app_label, model) 
values ('linked_urls',"urls", 'linked_urls'); 

शुरू में ठीक लग रहा है लेकिन वास्तविक क्वेरी निष्पादित किया गया था::

--# notice the caps case here - it looked so trivial, i didn't even bothered to look into it untill i realised what was happening internally 
INSERT INTO django_content_type(name, app_label, model) 
values ('Linked_Urls',"urls", 'Linked_Urls'); 

तो Django, आंतरिक रूप से, जब migrate कर रही है, सब कुछ सुनिश्चित करता है कम में माइग्रेट

जारी करना इस क्वेरी में झूठ बोला मामला - और यह समस्या थी !!

मेरे पास पिछले सभी प्रविष्टियों और voila को कम करने के लिए निष्पादित एक अलग क्वेरी थी!

3

हमने हाल ही में उत्पादन पर बनाए गए कुछ टेबल बनाए थे।

मैं दो तरीकों से जो लिखा है उसे पढ़ सकता हूं।

पहला तरीका: आपने SQL कथन के साथ तालिकाओं का निर्माण किया, जिसके लिए Django में कोई प्रासंगिक मॉडल नहीं हैं। यदि ऐसा है, तो सामग्री प्रकारों और अनुमतियों के साथ झुकाव की कोई मात्रा नहीं जो Django अचानक टेबल का उपयोग करेगी। आपको टेबल के लिए मॉडल बनाने की जरूरत है। शायद वे unmanaged होंगे, लेकिन उन्हें अस्तित्व में रहने की आवश्यकता है।

दूसरा तरीका: Django में संबंधित मॉडल मौजूद हैं, आपने मैन्युअल रूप से उनके लिए टेबल बनाए हैं, इसलिए यह कोई समस्या नहीं है। क्या मैं इस मामले में क्या चाहते हैं निम्नलिखित कोड चलता है, स्पष्टीकरण कोड के बाद का पालन करें:

from django.contrib.contenttypes.management import update_contenttypes 
from django.apps import apps as configured_apps 
from django.contrib.auth.management import create_permissions 

for app in configured_apps.get_app_configs(): 
    update_contenttypes(app, interactive=True, verbosity=0) 

for app in configured_apps.get_app_configs(): 
    create_permissions(app, verbosity=0) 

क्या कोड ऊपर करता है अनिवार्य रूप से काम करता है Django कि के बाद यह माइग्रेशन चलाता प्रदर्शन कर रहा है। जब माइग्रेशन होता है, तो Django बस आवश्यकतानुसार टेबल बनाता है, फिर जब यह किया जाता है, तो यह update_contenttypes पर कॉल करता है, जो प्रोजेक्ट में परिभाषित मॉडल से जुड़े तालिका को स्कैन करता है और जो भी जोड़ा जाना चाहिए django_content_type तालिका में जोड़ता है। इसके बाद create_permissions को auth_permissions अपडेट करने के लिए जोड़ने/जोड़ने/हटाने की अनुमतियों को अपडेट करने के लिए कॉल किया जाता है। मैंने उपरोक्त कोड का उपयोग during a migration के प्रारंभिक अनुमतियों को लागू करने के लिए किया है। यह उपयोगी है अगर मेरे पास डेटा माइग्रेशन है, उदाहरण के लिए, जो समूह बनाता है जिन्हें नई अनुमतियों को संदर्भित करने की आवश्यकता होती है।

+0

इसका दूसरा तरीका आपने उल्लेख किया है.अब, मेरी समस्या यह है कि मेरे पास प्रोड/प्री-प्रोड पर खोल पर चीजों को चलाने की पहुंच नहीं है। क्या कोई कच्चा 'एसक्यूएल 'सामान है जिसे मैं डीबीए को क्वेरी निष्पादित करने के लिए पास कर सकता हूं और काम पूरा हो गया? – NoobEditor

+0

आपको वह समस्या नहीं है। किसी भी Django प्रबंधन कमांड को पायथन कोड से 'django.core.management.call_command' को कॉल करके चलाया जा सकता है। यदि आप कोई ऐसा दृश्य बनाते हैं जो उस फ़ंक्शन को लपेटता है, तो आप जो कुछ भी चाहते हैं उसे चला सकते हैं। लेकिन, जब संदेह होता है, तो आप [subprocess] (https://docs.python.org/3/library/subprocess.html) लाइब्रेरी का उपयोग करके पाइथन से कमांड और ऐसे Django दृश्य को भी कॉल कर सकते हैं। और हाँ, दोनों तरीकों से आप माइग्रेशन चलाने की अनुमति देंगे। – Melvyn

संबंधित मुद्दे