Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Σε αυτή την περιοχή μπορείτε να βρείτε ή να αναζητήσετε πληροφορίες σχετικές με την PHP

Συντονιστές: WebDev Moderators, Super-Moderators

Απάντηση
Antonis78
Δημοσιεύσεις: 60
Εγγραφή: 24 Φεβ 2006 14:41

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από Antonis78 » 26 Σεπ 2013 14:20

Καλησπέρα, σε όλους.

Θέλω να φτιάξω μία εφαρμογή η οποία αυτήν την στιγμή έχει 5 user levels (με σειρά ιεραρχίας):

1) Admin (βλέπει τους πάντες)
2) Supervisor (βλεπει συγκεκριμένους Sales Admin)
3) Sales Admin (βλέπει συγκεκριμένους Account Managers)
4) Account Manager (βλέπει συγκεκριμένους Customers)
5) Customers

Εξηγώ:
- Ο κάθε Customer μπορεί να ανήκει σε ένα μόνο Account Manager.
- Ο καθε Account Manager μπορεί να ανήκει σε πολλούς Sales Admin (του ίδιου Supervisor όμως)
- Ο κάθε Sales Admin μπορεί να ανήκει σε έναν μόνο Supervisor
- Οι Admins θα πρέπει να μπορούν να βλέπουν τα πάντα

Όλοι μπορούν να βάλουν παραγγελίες αλλά δεν θέλω ο ένας να βλέπει του άλλου. Αν κάνω login σαν Sales Admin να βλέπω Customers που ανήκουν στους δικούς μου Account Managers και τις παραγγελίες αυτών.

Θα ήθελα κάποιος που έχει φτιάξει κάτι αντίστοιχο να μου δώσει κάποια ιδέα πως μπορώ να το υλοποιήσω. Με ενδιαφέρει να είναι όσο γίνεται πιο flexible ώστε αν στο μέλλον χρειαστεί να φτιάξω άλλο ένα level (πχ. ενδιάμεσα στον Supervisor και στον Sales Admin) να μην χρειάζεται να ξαναγράψω κώδικα (ή έστω ελάχιστο).

Ευχαριστώ πολύ
Συνημμένα
Hierarchy.jpg
Σχεδιάγραμμα Ιεραρχίας

Άβαταρ μέλους
Rapid-eraser
WebDev Moderator
Δημοσιεύσεις: 6851
Εγγραφή: 05 Απρ 2003 17:50
Τοποθεσία: Πειραιάς
Επικοινωνία:

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από Rapid-eraser » 26 Σεπ 2013 15:10

Από την στιγμή που θες να παίξεις με Role-based access control (RBAC) καλύτερα να στηθείς πάνω σε ένα role based ACL τύπου zend framework (Zend\Permissions\Acl)

Αν δεν χρησιμοποιήσει κάποιο framework που να έχει δικό του ACL σύστημα τότε μπορείς να πας σε κάποια lib τύπου
http://phprbac.net/

Για να το στήσεις μόνος σου αν έχεις όρεξη υπάρχει αρκετή θεωρία από πίσω.
Ένα ωραίο tutorial μπορείς να βρεις στο:
http://www.sitepoint.com/role-based-acc ... ol-in-php/
Cu, Rapid-eraser, Tα αγαθά copies κτώνται.
Love is like oxygen, You get too much you get too high
Not enough and you're gonna die, Love gets you high

Antonis78
Δημοσιεύσεις: 60
Εγγραφή: 24 Φεβ 2006 14:41

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από Antonis78 » 26 Σεπ 2013 16:35

Σε ευχαριστώ για την απάντηση. Δυστηχώς δεν μπορώ να δουλέψω κάποιο framework, πρέπει να γίνει custom.

Για την lib που παραθέτεις θα την τσεκάρω (δεν την ήξερα, thanks), θα διαβάσω και το tutorial μήπως πάρω ιδεές.

Για να καταλάβω όμως κάτι, αυτό που προτείνεις είναι role based, πως μπορεί να χρησιμοποιηθεί στην περίπτωσή μου; Εννοώ ότι εγώ θέλω να συνδέσω συγκεκριμένους χρήστες με άλλους και όχι group μεταξύ τους (πχ. ο Sales Admin Antonis78 ανήκει στον SUpervisor Rapid-eraser. Όταν κάνει login ο Rapid θα μπορεί να δει μόνο τους πελάτες του Antonis78).

Αυτά που μου προτείνεις θα μπορούν να χρησιμοποιηθούν με αυτόν τρόπο;

και πάλι σε ευχαριστώ

Άβαταρ μέλους
Rapid-eraser
WebDev Moderator
Δημοσιεύσεις: 6851
Εγγραφή: 05 Απρ 2003 17:50
Τοποθεσία: Πειραιάς
Επικοινωνία:

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από Rapid-eraser » 26 Σεπ 2013 16:51

Στο RBAC γενικώς παίζεις με κληρονομικότητα , Δηλαδή ο από πάνω μπορεί να κάνει ότι ο από κάτω συν κάτι έξτρα.

Τώρα αν αυτό λέγετε πρόσβαση σε παραγγελία που έχει κάνει κάποιος ή δυνατότητα να κάνει κάτι λειτουργικά παραπάνω είναι σχεδιαστικό θέμα για το πως θα το εκμεταλλευτείς εσύ.

Ακόμα και αν δεν σου αρέσει το συγκεκριμένο concept ρίξε μία ματιά για το πως λύνει τα διάφορα προβλήματα που συναντάς για την υλοποίησή του και θα βρεις πράγματα που θα μπορείς να τα υλοποιήσεις και αλλού.
Cu, Rapid-eraser, Tα αγαθά copies κτώνται.
Love is like oxygen, You get too much you get too high
Not enough and you're gonna die, Love gets you high

Antonis78
Δημοσιεύσεις: 60
Εγγραφή: 24 Φεβ 2006 14:41

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από Antonis78 » 26 Σεπ 2013 18:06

Μαλλον εγώ δεν μπορώ να το καταλάβω.

Ακούγοντας role based πάει το μυαλό μου σε ρόλους/γκρουπς χρηστών και όχι σε individual χρήστες και οι σχέσεις που έχω στο μυαλό μου είναι μεταξύ χρηστών (όπως στο παράδειγμα που σου είπα). Δηλαδή, μπορεί εγώ να ανήκω στο ίδιο γρουπ με εσένα (Supervisors) αλλά δεν πρέπει να μπορώ να βλέπω τους πελάτες σου. Έχω δικούς μου Sales Admin -> Account Managers -> Customers.

Κάπως έτσι:
Antonis78 (Supervisor) -> Manolis (Sales Admin) -> Vaggelis (Customer)
Rapid (Supervisor) -> Kostas -> (sales Admin) -> Nikos (Customer)

Αυτά τα λέω βέβαια χωρίς να έχω δει ακόμα αυτά που μου είπες οπότε μπορεί να ξεδιαλύνουν μετά.

και πάλι σε ευχαριστώ

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από geomagas » 26 Σεπ 2013 19:24

Μα και στη δική σου περίπτωση, ρόλους έχεις. "Ο Sales Admin" είναι ένας ρόλος (κλάση). "Ένας Sales Admin" είναι ένα άτομο (στιγμιότυπο).
Μόνο που, σ' αυτό που περιγράφεις, οι ρόλοι είναι flat, με την έννοια ότι δεν προκύπτει κληρονομικότητα από πουθενά, μόνο από το γεγονός ότι όλοι αυτοί είναι και χρήστες.
Επίσης, στη γενική περίπτωση, δεν αποκλείεται η συμμετοχή ενός στιγμιότυπου σε πάνω από μία κλάση (πχ ένας Supervisor μπορεί να είναι και Customer).

Οι σχέσεις των ρόλων μεταξύ τους υλοποιούνται με συσχετίσεις, ανάλογης πληθικότητας κατά περίπτωση.

Τέλος, το "τι βλέπει καθένας" υλοποιείται - για να προσθέσω κι εγώ έναν όρο - με Row-Level Security.

Antonis78
Δημοσιεύσεις: 60
Εγγραφή: 24 Φεβ 2006 14:41

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από Antonis78 » 27 Σεπ 2013 10:17

geomagas έγραψε:Μα και στη δική σου περίπτωση, ρόλους έχεις. "Ο Sales Admin" είναι ένας ρόλος (κλάση). "Ένας Sales Admin" είναι ένα άτομο (στιγμιότυπο).
Σωστά, τώρα μου είναι πιο ξεκάθαρο.
Στην πράξη όμως πως θα μπορώ να ξεχωρίσω ότι το στιγμιότυπο Antonis78 μπορεί να βλέπει μόνο τους πελάτες από το στιγμιότυπο Manolis; Σκέφτόμουν κάτι παρόμοιο με αυτό που χρησιμοποιώ για τις κατηγορίες προϊόντων, ένας πίνακας με τους users και ένα πεδίο parent όπου μπορώ να κάνω τον συσχετισμό μεταξύ τους. Αυτό το μοντέλο όμως δεν με βολεύει απόλυτα (πχ οι Sales Admins πρέπει να μπορούν να βλέπουν όλους τους πελάτες του Supervisor που ανήκουν).

Βρήκα και αυτό στο stackoverflow που μοιάζει με αυτό που θέλω να κάνω αλλά δεν μπορώ να το καταλάβω καλά.
geomagas έγραψε:Μόνο που, σ' αυτό που περιγράφεις, οι ρόλοι είναι flat, με την έννοια ότι δεν προκύπτει κληρονομικότητα από πουθενά, μόνο από το γεγονός ότι όλοι αυτοί είναι και χρήστες.
Βασικά υπάρχει περίπτωση να μην είναι και χρήστες. Εξηγώ:
Η εφαρμογή χωρίζεται σε 2 μέρη, "frontend" & "backend" (οι όροι δεν χρησιμοποιούνται κυριολεκτικά, απλά για να ξεχωρίσω τα 2 κομμάτια).
Το frontend είναι αυτό που δουλέυει ένας πελάτης που έιναι ΚΑΙ χρήστης (έχει username & password) και λειτουργεί σαν eshop περίπου (βάζει παραγγελίες, βλέπει αποθέματα, κτλ).
Το backend είναι αυτό που δουλέυουν οι υπάλληλοι και μπορούν να βλέπουν τους πελάτες τους (ανεξάρτητα αν είναι και χρήστες ή όχι), να βάζουν παραγγελίες, βλέπουν αποθέματα, κτλ.
geomagas έγραψε:Τέλος, το "τι βλέπει καθένας" υλοποιείται - για να προσθέσω κι εγώ έναν όρο - με Row-Level Security.
Διάβασα αυτό που μου παρέθεσες (thanks for that, δεν το είχα ακούσει καν και είναι ενδιαφέρον σαν concept) και απ' ότι κατάλαβα όλη η διαχείριση γίνεται στην βάση και όχι από την εφαρμογή, σωστά; Αυτό προϋποθέτει ο κάθε χρήστης της εφαρμογής να είναι και χρήστης της βάσης, κατάλαβα καλά; Αν ναι, θα ήθελα να το αποφύγω, προτιμώ να το κάνω στην εφαρμογή.

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από geomagas » 27 Σεπ 2013 11:34

Antonis78 έγραψε:
geomagas έγραψε:Μα και στη δική σου περίπτωση, ρόλους έχεις. "Ο Sales Admin" είναι ένας ρόλος (κλάση). "Ένας Sales Admin" είναι ένα άτομο (στιγμιότυπο).
Σωστά, τώρα μου είναι πιο ξεκάθαρο.
Στην πράξη όμως πως θα μπορώ να ξεχωρίσω ότι το στιγμιότυπο Antonis78 μπορεί να βλέπει μόνο τους πελάτες από το στιγμιότυπο Manolis; Σκέφτόμουν κάτι παρόμοιο με αυτό που χρησιμοποιώ για τις κατηγορίες προϊόντων, ένας πίνακας με τους users και ένα πεδίο parent όπου μπορώ να κάνω τον συσχετισμό μεταξύ τους. Αυτό το μοντέλο όμως δεν με βολεύει απόλυτα (πχ οι Sales Admins πρέπει να μπορούν να βλέπουν όλους τους πελάτες του Supervisor που ανήκουν).
Μα γι' αυτό είπα ότι οι σχέσεις των ρόλων μεταξύ τους υλοποιούνται με συσχετίσεις, ανάλογης πληθικότητας κατά περίπτωση.
Με άλλα λόγια, ενώ αυτό που λες θα σε βόλευε για τη σχέση AccountManager<-->Customer, επειδή είναι 1:Ν, δεν σε βολεύει για τη σχέση SalesAdmin<-->AccountManager, διότι αυτή είναι Μ:Ν. Άλλη πληθικότητα.
Antonis78 έγραψε:
geomagas έγραψε:Μόνο που, σ' αυτό που περιγράφεις, οι ρόλοι είναι flat, με την έννοια ότι δεν προκύπτει κληρονομικότητα από πουθενά, μόνο από το γεγονός ότι όλοι αυτοί είναι και χρήστες.
Βασικά υπάρχει περίπτωση να μην είναι και χρήστες. Εξηγώ:
Η εφαρμογή χωρίζεται σε 2 μέρη, "frontend" & "backend" (οι όροι δεν χρησιμοποιούνται κυριολεκτικά, απλά για να ξεχωρίσω τα 2 κομμάτια).
Το frontend είναι αυτό που δουλέυει ένας πελάτης που έιναι ΚΑΙ χρήστης (έχει username & password) και λειτουργεί σαν eshop περίπου (βάζει παραγγελίες, βλέπει αποθέματα, κτλ).
Το backend είναι αυτό που δουλέυουν οι υπάλληλοι και μπορούν να βλέπουν τους πελάτες τους (ανεξάρτητα αν είναι και χρήστες ή όχι), να βάζουν παραγγελίες, βλέπουν αποθέματα, κτλ.
Δηλαδή εννοείς ότι όλοι οι υπόλοιποι, εκτός τους πελάτες, δεν πιστοποιούνται από το σύστημα; Αμφιβάλλω...
Χρήστης νοείται κάθε οντότητα που έχει στοιχεία πιστοποίησης και μπορεί να αναγνωριστεί από το σύστημα ώστε αυτό να μπορεί να εφαρμόσει κανόνες ασφαλείας. Συμπεριλαμβανομένων αυτών που θέλεις να κάνεις (πχ αν δεν με αναγνωρίσει το σύστημα σαν AccountManager, πως θα μου "φιλτράρει" να βλέπω μόνο τους πελάτες μου; ).
Antonis78 έγραψε:
geomagas έγραψε:Τέλος, το "τι βλέπει καθένας" υλοποιείται - για να προσθέσω κι εγώ έναν όρο - με Row-Level Security.
Διάβασα αυτό που μου παρέθεσες (thanks for that, δεν το είχα ακούσει καν και είναι ενδιαφέρον σαν concept) και απ' ότι κατάλαβα όλη η διαχείριση γίνεται στην βάση και όχι από την εφαρμογή, σωστά; Αυτό προϋποθέτει ο κάθε χρήστης της εφαρμογής να είναι και χρήστης της βάσης, κατάλαβα καλά; Αν ναι, θα ήθελα να το αποφύγω, προτιμώ να το κάνω στην εφαρμογή.
Τυπικά, υλοποιείται στο επίπεδο της ΒΔ. Και αυτό θα σου πρότεινα ανεπιφύλακτα να κάνεις, αν έχεις τη δυνατότητα. Αν όχι, μπορείς να το υλοποιήσεις και στην εφαρμογή. Αλλά:
- θα πρέπει να γράψεις περισσότερο κώδικα
- το κυριότερο, δεν θα είναι ασφαλές. Σίγουρα θα επεμβαίνεις στη ΒΔ παρακάμπτοντας το interface (πχ από phpmyadmin), και υπάρχει περίπτωση να τα κάνεις λίγο... bahalo...

Antonis78
Δημοσιεύσεις: 60
Εγγραφή: 24 Φεβ 2006 14:41

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από Antonis78 » 27 Σεπ 2013 12:26

geomagas έγραψε:Μα γι' αυτό είπα ότι οι σχέσεις των ρόλων μεταξύ τους υλοποιούνται με συσχετίσεις, ανάλογης πληθικότητας κατά περίπτωση.
Με άλλα λόγια, ενώ αυτό που λες θα σε βόλευε για τη σχέση AccountManager<-->Customer, επειδή είναι 1:Ν, δεν σε βολεύει για τη σχέση SalesAdmin<-->AccountManager, διότι αυτή είναι Μ:Ν. Άλλη πληθικότητα.
Οπότε, ας πούμε ένας πίνακας με τα relations μεταξύ χρηστών θα ήταν κάτι που θα με βόλευε;
πχ

users_relations
parent | 1 | 1
child | 2 | 3

κτλ...
geomagas έγραψε:Δηλαδή εννοείς ότι όλοι οι υπόλοιποι, εκτός τους πελάτες, δεν πιστοποιούνται από το σύστημα; Αμφιβάλλω...
Χρήστης νοείται κάθε οντότητα που έχει στοιχεία πιστοποίησης και μπορεί να αναγνωριστεί από το σύστημα ώστε αυτό να μπορεί να εφαρμόσει κανόνες ασφαλείας. Συμπεριλαμβανομένων αυτών που θέλεις να κάνεις (πχ αν δεν με αναγνωρίσει το σύστημα σαν AccountManager, πως θα μου "φιλτράρει" να βλέπω μόνο τους πελάτες μου; ).
Όχι, εννοώ ότι μέχρι και τους Account Managers, όλοι έχουν στοιχεία πιστοποίησης. Οι πελάτες όμως δεν έχουν όλοι, γιατί δεν έχουν όλοι πρόσβαση στην εφαρμογή. Υπάρχουν όμως σαν πελάτες γιατί πρέπει να τους βλέπει ο Account Manager και να μπορεί να βάλει παραγγελία σε αυτούς. Άσχετο/Σχετικό: διάβασα και στο blog σου για IS-A relationships και ίσως να χρειάζομαι και εγώ κάτι τέτοιο, ε;
geomagas έγραψε:Τυπικά, υλοποιείται στο επίπεδο της ΒΔ. Και αυτό θα σου πρότεινα ανεπιφύλακτα να κάνεις, αν έχεις τη δυνατότητα. Αν όχι, μπορείς να το υλοποιήσεις και στην εφαρμογή. Αλλά:
- θα πρέπει να γράψεις περισσότερο κώδικα
- το κυριότερο, δεν θα είναι ασφαλές. Σίγουρα θα επεμβαίνεις στη ΒΔ παρακάμπτοντας το interface (πχ από phpmyadmin), και υπάρχει περίπτωση να τα κάνεις λίγο... bahalo...
Η αλήθεια είναι ότι οι γνώσεις μου στην php είναι καλύτερες απ' ότι στις ΒΔ και για αυτό προτιμώ να το κάνω εκεί. Δεν με πειράζει να γράψω περισσότερο κώδικα, όσο για την ασφάλεια το καταλαβαίνω αυτό που λες αλλά είμαι πολύ προσεκτικός σε τέτοιες περιπτώσεις. Δεν βάζω χέρι στην ΒΔ παρά μόνο αν ΔΕΝ υπάρχει κανένας άλλος τρόπος.

By the way, σε ευχαριστώ για τον χρόνο σου! :) :)

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από geomagas » 27 Σεπ 2013 13:34

Antonis78 έγραψε:
geomagas έγραψε:Μα γι' αυτό είπα ότι οι σχέσεις των ρόλων μεταξύ τους υλοποιούνται με συσχετίσεις, ανάλογης πληθικότητας κατά περίπτωση.
Με άλλα λόγια, ενώ αυτό που λες θα σε βόλευε για τη σχέση AccountManager<-->Customer, επειδή είναι 1:Ν, δεν σε βολεύει για τη σχέση SalesAdmin<-->AccountManager, διότι αυτή είναι Μ:Ν. Άλλη πληθικότητα.
Οπότε, ας πούμε ένας πίνακας με τα relations μεταξύ χρηστών θα ήταν κάτι που θα με βόλευε;
πχ

users_relations
parent | 1 | 1
child | 2 | 3

κτλ...
Γενικά όχι. Αυτό είναι που λέω "κατα περίπτωση".
Στην περίπτωση του customer, αρκεί ένα ξένο κλειδί προς τον αντίστοιχο AccountManager.
Αλλά στην περίπτωση του SalesAdmin<-->AccountManager, επειδή είναι Μ:Ν, θέλεις ξεχωριστό πίνακα συσχέτισης (=αυτό που περιγράφεις, αν το κατάλαβα καλά).
Antonis78 έγραψε:
geomagas έγραψε:Δηλαδή εννοείς ότι όλοι οι υπόλοιποι, εκτός τους πελάτες, δεν πιστοποιούνται από το σύστημα; Αμφιβάλλω...
Χρήστης νοείται κάθε οντότητα που έχει στοιχεία πιστοποίησης και μπορεί να αναγνωριστεί από το σύστημα ώστε αυτό να μπορεί να εφαρμόσει κανόνες ασφαλείας. Συμπεριλαμβανομένων αυτών που θέλεις να κάνεις (πχ αν δεν με αναγνωρίσει το σύστημα σαν AccountManager, πως θα μου "φιλτράρει" να βλέπω μόνο τους πελάτες μου; ).
Όχι, εννοώ ότι μέχρι και τους Account Managers, όλοι έχουν στοιχεία πιστοποίησης. Οι πελάτες όμως δεν έχουν όλοι, γιατί δεν έχουν όλοι πρόσβαση στην εφαρμογή. Υπάρχουν όμως σαν πελάτες γιατί πρέπει να τους βλέπει ο Account Manager και να μπορεί να βάλει παραγγελία σε αυτούς. Άσχετο/Σχετικό: διάβασα και στο blog σου για IS-A relationships και ίσως να χρειάζομαι και εγώ κάτι τέτοιο, ε;
Ναί αλλά μόνο σε ένα επίπεδο, τουλάχιστον αυτό συμπεραίνω από τα λεγόμενά σου.
Έχεις μία υπερκλάση user (username [pk], password) κι έπειτα:
- Admin is-a user
- Supervisor is-a user
- SalesAdmin is-a user
- AccountManager is-a user
- RegisteredCustomer is-a user

Με τη διαφοροποίηση που πρόσθεσες για τους πελάτες (μπορεί να είναι χρήστες ή όχι) έχεις και την
Customer (id [pk],account_manager [fk AccountManager])
και μετά
RegisteredCustomer is-a Customer

Antonis78
Δημοσιεύσεις: 60
Εγγραφή: 24 Φεβ 2006 14:41

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από Antonis78 » 27 Σεπ 2013 13:54

Οκ, για το IS-A χρειάζομαι ένα πίνακα users και μετά ένα πίνακα ανά user level; Κάπως έτσι;

Users
id (pk)
username (unique)
password

Admins
id (pk)
name
userid (fk -> users)

Supervisors
id (pk)
name
userid (fk -> users)

Sales Admin
id (pk)
name
userid (fk -> users)

Account Manager
id (pk)
name
userid (fk -> users)

Customer
id (pk)
name
accountmanagerid (fk -> accountmanagers)

RegisteredCustomer
customerid (fk -> customers)
userid (fk -> users)

Από εδώ πως θα μπορούσα να ενσωματώσω και τις συσχετίσεις; Εσύ πως θα υλοποιούσες κάτι τέτοιο;

Και πάλι ευχαριστώ, γιατί μαλλον σου τρώω χρόνο από την δουλειά σου :D :D :D

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από geomagas » 27 Σεπ 2013 15:37

Antonis78 έγραψε:Οκ, για το IS-A χρειάζομαι ένα πίνακα users και μετά ένα πίνακα ανά user level; Κάπως έτσι;

Users
id (pk)
username (unique)
password
(Καλά ως εδώ, αλλά εγώ θα κρατούσα το username σαν PK, αφού εκ φύσεως είναι το μοναδικό αναγνωριστικό της πλειάδας στο σύστημα. Δεν χρειάζεται id.)
Παρατηρώ ότι συμπεριλαμβάνεις το name σε όλες τις κλάσεις εκτός του RegisteredCustomer. Θα πρέπει να είναι κάπου κεντρικά.

Έστω λοιπόν ότι προσθέτουμε άλλο ένα επίπεδο στην ιεράρχηση:

person (id [pk],name)

- Ένας user είναι πάντα και person, αλλά δεν ισχύει πάντα και το αντίστροφο (βλ. πελάτες).
- Ένας customer είναι επίσης πάντα και person. Επιπλέον, "ανήκει" σε έναν και μόνο AccountManager.
- Ένας RegisteredCustomer είναι συγχρόνως customer αλλά και user.
Οπότε

User (person [pk][fk Person], username, password)
Customer(person [pk][fk Person], account_manager [fk AccountManager])
RegisteredCustomer(customer [pk][fk Customer][fk User])


Αν δεις και στο άρθρο, λέω ότι για να είναι σχέση is-a θα πρέπει το PK να είναι συγχρόνως και FK στην υπερκλάση (δες τα bold).
Αυτό το λέω για τα παρακάτω, όπου προσπαθείς να υλοποιήσεις τη σχέση is-a με απλό FK.
Antonis78 έγραψε: Admins
id (pk)
name
userid (fk -> users)

Supervisors
id (pk)
name
userid (fk -> users)

Sales Admin
id (pk)
name
userid (fk -> users)
Κατά τον ίδιο τρόπο με παραπάνω, αφού
- ο Admin είναι user
- ο Supervisor είναι user αλλά και ανήκει σε έναν Admin
- ο SalesAdmin είναι user αλλά και ανήκει σε έναν Supervisor

Admin(user [pk][fk User])
Supervisor(user [pk][fk User], admin [fk Admin])
SalesAdmin(user [pk][fk User], supervisor [fk Supervisor])
Antonis78 έγραψε: Account Manager
id (pk)
name
userid (fk -> users)
Ο AccountManager είναι και user, οπότε

AccountManager(user [pk][fk User])

Εδώ τώρα έχουμε τη σχέση M:N, και θα πρέπει να υλοποιήσουμε μία συσχέτιση:

SalesAdmin2AccountManager(sales_admin [fk SalesAdmin],account_manager [fk AccountManager], pk(sales_admin,account_manager) )
Antonis78 έγραψε: Και πάλι ευχαριστώ, γιατί μαλλον σου τρώω χρόνο από την δουλειά σου :D :D :D
Δε βαριέσαι... Ας κάνουμε και κάτι πιο ενδιαφέρον να ξεφύγουμε... :D

alou
Script Master
Δημοσιεύσεις: 1374
Εγγραφή: 24 Αύγ 2007 19:52
Επικοινωνία:

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από alou » 27 Σεπ 2013 17:10

Ωραία κουβέντα :D

Δεν είναι πιο απλό να υπάρχει ένα pivot με user_id - parent_user_id (για κάθε parent στην ιεραρχία) και ένα πεδίο access_level στον users;

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από geomagas » 27 Σεπ 2013 17:51

Όχι, διότι αυτό δεν σου εξασφαλίζει τη ζητούμενη ιεραρχία.
Π.χ. πως θα εξασφαλίσεις ότι ο κάθε SalesAdmin θα έχει ακριβώς έναν Supervisor, ενώ κάθε AccountManager θα ανήκει σε Ν SaleAdmins (και θα έχει και Κ πελάτες);

Επίσης, δεν είναι θέμα access level, με την έννοια ότι ο ρόλος Α έχει τόσα δικαιώματα όσα και ο Β, συν κάποια παραπάνω. Έχει να κάνει με το scope των δεδομένων τα οποία μπορεί ο καθένας να βλέπει, και επιπλέον (αν κατάλαβα καλά) ο κάθε ρόλος έχει τις δικές του αρμοδιότητες.

Αυτό που λες μπορεί να χρησιμοποιηθεί για να υλοποιήσει μία δενδρική δομή ομοειδών οντοτήτων, αλλά εδώ δεν έχουμε τέτοια περίπτωση.

Antonis78
Δημοσιεύσεις: 60
Εγγραφή: 24 Φεβ 2006 14:41

Διαχείριση Ιεραρχίας Χρηστών (User Levels)

Δημοσίευση από Antonis78 » 27 Σεπ 2013 18:31

Λοιπόν, έχω αρχίσει και το πιάνω το νόημα (εντάξει, μου κάνεις ιδιαίτερα και δεν το έχεις καταλάβει, έτσι; :D :D :D )

Θα κάτσω να σχεδιάσω την βάση και επανέρχομαι. Μία ερώτηση, αν χρειαστώ και καινούργιο level, ας πούμε ανάμεσα από τον Admin & Supervisor (SubAdmin), θα χρειαστώ καινούργιο πίνακα, σωστά; Επίσης, να κάνω και τις σχέσεις μεταξύ τους, ε;

Χαίρομαι που η συζήτησή μας σου είναι ενδιαφέρουσα.

@alou: ο geomagas έχει δίκιο. Το πρόβλημά μου δεν είναι δικαιώματα αλλά scope δεδομένων. Η ιδέα σου είναι αυτό που είχα σκεφτεί στην αρχή αλλά τελικά δεν κάνει. Ευχαριστώ πάντως!

Απάντηση

Επιστροφή στο “PHP Προγραμματισμός”

Μέλη σε σύνδεση

Μέλη σε αυτήν τη Δ. Συζήτηση: Δεν υπάρχουν εγγεγραμμένα μέλη και 1 επισκέπτης