Extend Organisation with a uuid property and setter.

[byrman]

Changing unique_id into a UUIDField might break things (?), but a separate property seems both harmless and useful (e.g. for serializing unique_id as a proper UUID).

[coveralls]

Coverage decreased (-0.04%) to 75.0% when pulling d26de1c on byrman_uuid into d0f82cd on master.

[reinout]

Nog even kijken of er een commentaarregel bij het veld danwel de property moet.

[caspervdw]

Is het mogelijk om er ook een validator aan te hangen zodat wanneer een unique_id in de admin wordt ingevuld, wordt gecheckt of het een valide UUID is?

Op dit moment gaat dat regelmatig fout.

[byrman]

Op dit moment gaat dat regelmatig fout.

Hoe dan?

[byrman]

Ah, je bedoelt in Lizard i.p.v. SSO? Raar dat je daar organisaties kunt aanmaken, want dat zou alleen in de SSO moeten gebeuren.

[caspervdw]

Ja, ik bedoel in Lizard. De organisaties in de SSO worden genegeerd door Lizard (en door 3Di ook geloof ik).

[byrman]

Ja, ik bedoel in Lizard. De organisaties in de SSO worden genegeerd door Lizard (en door 3Di ook geloof ik).

Dat is nooit de bedoeling geweest: organisaties zouden maar op 1 plek worden gegenereerd. Alleen dan gebruiken Lizard en 3Di dezelfde UUIDs voor dezelfde organisaties.

Anyway, jouw probleem moet dus in Lizard worden opgelost en niet in deze repo?

[caspervdw]

Als ik reinout goed begrijp, dan is de aanwezigheid van een Organisation model in de SSO een overblijfsel van eerdere tijden toen authorisatie ook nog op de SSO werd geregeld. Nu doet SSO alleen authenticatie. Users mogen wel lid zijn van een organisatie op de SSO, applicaties doen helemaal niets met die info.

Het organisation model in Lizard staat gedefinieerd in lizard-auth-client, dus het is het makkelijkst om een model-field-validator aan het model in deze repo te hangen.

[reinout]

Ah, dit is de lizard/3di-versie van het organisation model. Ik haalde lizard-auth-server en -client even door elkaar en dacht dat dit een wijziging op de SSO was :-)

Ik mis waarschijnlijk wat achtergrond: gaat het wel goed met de coordinatie tussen 3di en lizard dan? SSO (lizard-auth-server) zit de uuid niet in. Lizard en 3di gaan elk een ander uuid genereren als het goed is. => huh?

Maar goed, het zal wel nodig zijn voor de amazon koppeling?

[byrman]

Als ik reinout goed begrijp

Volgens mij zit het toch echt anders: SSO doet authenticatie èn definieert organisaties. Lid maken van een organisatie doet de SSO niet meer, maar dat heb ik ook nooit beweerd.

dus het is het makkelijkst om een model-field-validator aan het model in deze repo te hangen.

Dat breekt tests onmiddellijk (maar is te fixen) en is niet backward compatible. Ik weet niet of andere applicaties ook echt UUIDs gebruiken. Dat is alleen zo als ze gebruik maken van de automatische gegenereerde waarden.

[caspervdw]

Ik mis waarschijnlijk wat achtergrond: gaat het wel goed met de coordinatie tussen 3di en lizard dan? SSO (lizard-auth-server) zit de uuid niet in. Lizard en 3di gaan elk een ander uuid genereren als het goed is. => huh?

Volgens mij zit het toch echt anders: SSO doet authenticatie èn definieert organisaties. Lid maken van een organisatie doet de SSO niet meer, maar dat heb ik ook nooit beweerd.

De organisatie-uuids worden handmatig gelijk gehouden tussen Lizard en SSO; applicatiebeheer gebruikt hier copy-paste voor. Het proces van een nieuwe organisatie toevoegen is: Organisation aanmaken in SSO, UUID kopieren, Organisation aanmaken in Lizard. Hier gaat het vaak fout omdat de streepjes niet worden verwijderd.

Dat breekt tests onmiddellijk (maar is te fixen) en is niet backward compatible. Ik weet niet of andere applicaties ook echt UUIDs gebruiken. Dat is alleen zo als ze gebruik maken van de automatische gegenereerde waarden.

Goed punt, ik kan alleen geen voorbeelden bedenken. Ik denk dat we wel het risico kunnen nemen dat andere applicaties hierop breken. Het veld is duidelijk bedoeld geweest als UUID.

[reinout]

Ok, duidelijk.
Inderdaad, er stáát gewoon al een unique_nogwat in lizard-auth-server :-)