#django #drf #python #programowanie

Jestem w trakcie nauki Django Rest Framework i zastanawiam się, gdzie umieszczać logikę niezwiązaną z bazy danych, np wywołanie zewnetrznego API na podstawie przekazanego parametru do naszego API, wykonać jakieś operacje na plikach itp itd. plik models.py nie wydaję mi się odpowiednim miejscem. W innych frameworkach tj Symfony, Laravel wiadomo gdzie takie rzeczy wsadzać ale to są framworki typu MVC a django jest MVT i ciut się zgubiłem.
Dwa pytanka do ekspertów: czy zastosowanie pola ManyToManyField jako listy użytkowników mających mieć pozwolenie na dostęp do tego obiektu jakieś zasadnicze wady?

robię sobie wtedy permission:

[...]
def hasobjectpermission(self, request, view, obj):
....if view.action == ['retrieve', 'partial_update']:
........return request.user in obj.testers.all() or request.user == obj.owner
[...]

Czy z jakiegoś powodu potrzebuję django groups i od tej strony gryźć?

Drugie pytanie: Docelowo chcę wprowadzić rozwiązanie w którym tylko owner może w
@IamHater:
Użyj wbudowanych grup i permissionów
W permissionach bedziesz mial canview, cancomment, can_edit itd itp
W grupach - tester/owner/viewer

M2M się nie sprawdzi, bedzie ciezsze w utrzymaniu, nie potrzebujesz calego modelu uzytkownika, a permissiony sa natywnie wspierane przez django wiec po co kombinujesz jak kon pod góre

I swoją drogą to jak bedziesz sprawdzał czy ktoś ma uprawnienia? if user in obj.testers.all() or user in obj.owners.all() or user in
wiec po co kombinujesz jak kon pod góre


@Lunatik: Jakbym wiedział że to tak wygląda to bym w kunia się nie bawił ( ͡° ͜ʖ ͡°) Po prostu wyszedłem od custom permissions wykonywanych przez viewsety. Jeżeli DjangoModelPermissions będzie lepsze to się przyjrzę.

if user in obj.testers.all() or user in obj.owners.all() or user in obj.admins.all() ? bez sensu


Hm, nie no, jest tylko jeden owner i grupa testerów.
#django #djangorestframework #drf #programowanie #python

mam coś takiego: zwykły model User z django.contrib.auth i model Profile, który ma usera jako ForeignKey
class Profile(models.Model):
    user = models.ForeignKey(User, related_name='profile')
    # ofc jakieś inne pola tutaj

mam też model Activity, który ma ForeignKey(User), ale nie ma pola Profile i teraz próbuję zrobić zagnieżdżony serializer:

class ActivitySerializer(ModelSerializer):
    user = UserSerializer()
    profile = ProfileSerializer() # tutaj jest mój problem, chciałbym na podstawie Usera pobrać
@buntuubuntu: robisz tabele Day ktory ma jedno pole i to jeszcze datetime zamiast date. w profilu dales pole m2m do day przez drinkingday, troche bez sensu. tabela day nie powinna istniec, drinkingday powinien miec klucz obcy do User a Profil nie powinien miec pola days.

zalogowany uzytkownik powinien miec mozliwosc edycji tylko wlasnego profilu, jestes pewny, ze nie mozna edytowac czyjegos profilu? ;-)

zapytanie o profil ( w api) tez powinno
1. Przy tworzeniu requirementsów możnaby napisać że to rozwiązanie tymczasowe, lecz dość ryzykowne ( ͡° ͜ʖ ͡°)
2. Serio nie rozumiem tendencji rozbijania uzytkownika na "uzytkownika" i "profil". Przecież Djagno oferuje mozliwosc używania wlasnego modelu to uwierzytelniania, dlaczego by nie skorzystać? Czemu ma służyć na struktura?
3. Sygnały to surprise driven development ( ͡° ͜ʖ ͡°)
4. Jeżeli piszesz po angielsku to użyj czegoś
Pytanie odnośnie REST API - nie wiem czy dobrze rozumiem
(moje REST API pisze w django rest frameworku)

Mam taka aplikacje gdzie model w basie danych ma relacje z częsciami samochodowymi ( wszystkie czesći muszą być powiązane tylko z jednym samochodem - to tylko przykład)
mam takie endpointy:

GET POST samochody/ - lista samochodów , mozliwośc stworzenia nowego;
GET PUT DELETE samochody// - opis samochodu , oraz wpięte do odnośnika 'cześci samochodowe",