[Datamodel] dubbele koppeltabel

[Icey]

Ik heb drie modellen, een gebruiker (user), organisatie (company) en project (eeehm).

• Een gebruiker is gekoppeld aan één of meerdere organisaties
• Een organisatie is gekoppeld aan één of meerdere projecten
• Een project is gekoppeld aan één of meerdere gebruikers

Bovenstaande werkt; maar voor mijn gevoel klopt dit niet. Alle gebruikers kunnen nu aan een projecten gekoppeld worden terwijl je eigenlijk alleen de gebruikers die aan de betreffende organisatie zijn gekoppeld wilt kunnen toevoegen.

Zie ik iets over het hoofd? Of klopt mijn hele datamodel gewoon niet. Laravel biedt wel de mogelijkheid om te filteren op de pivot velden maar dat is in dit geval niet van toepassing. En ze hebben wel een hasManyThrough maar die werkt niet met een many-to-many.

[armageddon_2k1]

Bovenstaande werkt; maar voor mijn gevoel klopt dit niet. Alle gebruikers kunnen nu aan een projecten gekoppeld worden terwijl je eigenlijk alleen de gebruikers die aan de betreffende organisatie zijn gekoppeld wilt kunnen toevoegen.

Oh? Is dat dan een harde eis? Wat nou als je een consultant van bedrijf A hebt die mee gaat doen bij een project van bedrijf B?

De vraag is of users onderdeel zijn van een project of dat users meewerken aan een project. Semantisch een verschil.

[ Voor 14% gewijzigd door armageddon_2k1 op 10-03-2022 15:09 ]

[Icey]

In mijn optiek zou hij dan eerst gekoppeld moeten worden aan bedrijf B. Laat ik het anders zeggen; als iemand van bedrijf A inlogt ziet hij alleen zijn eigen gebruikers en niet die van bedrijf B.

[Kontsnorretje]

Je laatste antwoord helpt niet... Een gebruiker kan aan 1 of meerdere organisaties gekoppeld worden stel je in de eisen.

De situatie die armageddon schetst is dus zeker van toepassing op het moment dat een gebruiker aan 2 of meer bedrijven en projecten is gekoppeld. Dit scenario merk ik ook binnen mijn werk, waar ik bij bedrijf X werk, en voor bedrijf A, B en C hun tickets beheer (wat overeen lijkt te komen met jou situatie).

Ik mis in deze een beetje de autorisatie. De project_user tabel uitbreiden met een company kolom kan een eerste stap zijn (al kan je die al herleiden uit de company_user tabel).

[Knutselsmurf]

Volgens mij kun je dit opvangen door de project-user niet direct naar de user te laten wijzen, maar naar de company-user

[Artaex]

Ik denk dat je project_user weg wilt halen. Er is een package waarmee je diepere relaties kunt maken: https://github.com/staudenmeir/eloquent-has-many-deep

Daarmee zou het moeten lukken om vanaf een user via companies alle projects op te halen.

[Knutselsmurf]

Artaex schreef op vrijdag 11 maart 2022 @ 09:40:
Ik denk dat je project_user weg wilt halen. Er is een package waarmee je diepere relaties kunt maken: https://github.com/staudenmeir/eloquent-has-many-deep

Daarmee zou het moeten lukken om vanaf een user via companies alle projects op te halen.

De vraag gaat niet over het ophalen van de beschikbare projecten, maar over het koppelen van projecten aan gebruikers. Als ik de vraagstelling goed begrepen heb, is het juist de bedoeling om users specfiek aan projecten te kunnen koppelen.

Als de koppeling tussen gebruikers en projecten echter een op zichzelf staande koppeling is, is het lastiger om bij verbreken/beëindigen van de company-user relatie ook direct de koppeling tussen de user en de projecten van die company te beëindigen.

Door, zoals ik al eerder had geschreven, de koppeling van project_user niet naar user te leggen, maar naar compay_user, is bij het verbreken van de koppeling tussen copany en user direct helder welke projecten bij die specifieke koppeling horen en dus inactief gemaakt moeten worden.

Op welke wijze dat laatste gebeurt is uiteindelijk afhankelijk van de wijze waarop de koppeling wordt bijgehouden.

Persoonlijk ben ik er voorstander van om in situaties als deze in zowel de company_user and project_user de geldigheid bij de houden met een datum/timestamp van/tot. Beëindiging van de betreffende koppeling gebeurt dan niet door het verwijderen van een record in de koppeltabel maar door de einddatum in te vullen. Op die maier blijft de historie beschikbaar over wie wanneer toegang heeft gehad.

[Woy]

Ik heb de titel even aangepast, aangezien het niet een vraag specifiek voor Laravel is.

[Orion84]

Icey schreef op donderdag 10 maart 2022 @ 14:31:
Bovenstaande werkt; maar voor mijn gevoel klopt dit niet. Alle gebruikers kunnen nu aan een projecten gekoppeld worden terwijl je eigenlijk alleen de gebruikers die aan de betreffende organisatie zijn gekoppeld wilt kunnen toevoegen.

De hamvraag is of dat iets is wat je in je datamodel moet willen oplossen. Dit is iets dat je prima in je applicatie logica kan afdwingen. Of desnoods met constraints op je DB (geen idee of dat hier echt helemaal van toepassing / bruikbaar voor is, maar je zou daar eens naar kunnen kijken).

[Icey]

Ik denk dat je gelijk hebt @Orion84; met behoud van standaard Laravel relaties kan ik het simpelweg oplossen binnen de applicatie. In dit geval Laravel Nova.

PHP:

/**
     * Build a "relatable" query for the given resource.
     *
     * This query determines which instances of the model may be attached to other resources.
     *
     * @param  \Laravel\Nova\Http\Requests\NovaRequest  $request
     * @param  \Illuminate\Database\Eloquent\Builder  $query
     * @param  \Laravel\Nova\Fields\Field  $field
     * @return \Illuminate\Database\Eloquent\Builder
     */
    public static function relatableProjects(NovaRequest $request, $query)
    {
        $resourceId = $request->route('resourceId'); 

        return $query
            ->select('projects.*')
            ->join('companies', 'companies.id', '=', 'projects.company_id')
            ->join('company_user', 'company_user.company_id', '=', 'companies.id')
            ->where('company_user.user_id', $resourceId);
    }