Mail account beter in userbeheer ?

[mdekraa]

Wij hebben al alle personen hier geidentificeerd met hun personeelsnummer (wordt o.a. gebruikt in d emodule klachten)
Betekent dit dat we dat allemaal moeten omzetten of dubbelen naar userId's voordat de mailfunctie werkt? waarom is de referentie naar de mail account niet gewoon onderdeel van userbeheer?
Is niet zo slim opgezet .... lijkt mij

marco

[Peter Stordiau]

Marco,

Ik heb dit even in een apart topic gezet (waar jij het in Funktie-trigger Workflow toegevoegd - missend bestand map LOPW? plaatste);

Aldaar snapte ik de context al niet, en nu gelukkig helemaal niet meer. Maar daarom juist : ik had even geen zin om een niet-gerelateerd onderwerp weer helemaal door te lezen om w.s. tot de konklusie te komen dat ... het niet gerelateerd was. Ofwel :

Nu het toch in een apart topic staat, kan je het van een context voorzien die ik kan volgen (ja, ik ).

[mdekraa]

Snap ik, maar de uitleg dat je het zo moet inrichten kon ik alleen daar terug vinden.
Maar het was inderdaad mooier geweest als ik zelf een nieuw topic had gemaakt met verwijzing naar de uitleg in het workflow deel.

[Peter Stordiau]

"Zo moet inrichten" ? Je hebt nog niet eens verteld wat je wilt doen !?

Maar daar ben je nu mee bezig hoop ik ...

[mdekraa]

Ik was een eerste voorzichtige kijk aan het nemen naar het mailen van inkoop en verkooporderbevestigingen
maar toen kwam ik tegen dat je daneerst de user mail-Id bekend moest maken in heart
...

[Robert Hekkers]

Moeten is een te groot woord; "het kan nodig zijn" dekt de lading beter.

Alles hangt af van of jullie mail-server ook bij uitgaande mail een authenticatie vereist.
Zo niet, dan hoef je userid/password ook niet in te vullen.

[Peter Stordiau]

Ik denk dat het verhaal iets anders is ...

Ten eerste, het mailen in Profit is zo opgezet dat het de Kontaktpersoon bij een Relatie is die de email verstuurt dan wel ontvangt. Dit is misschien niet zo maar te raden, maar zo is het wel en dit is ook minder verkeerd als je denkt, als je eerst even normaliseert. Hieruit enkele puntjes :

Als iemand een email moet ontvangen, zal deze toch zeker niet als User (entiteit Gebruikers) in het systeem gedefinieerd moeten zijn ?
Juist.
Als iemand een email moet ontvangen, en dat gebeurt op een bepaald email adres, dan zal het toch niet zo zijn dat de feitelijk zelfde benodigde gegevens voor het versturen van een email plots nogmaals, en dan elders moeten of mogen worden geregistreerd (zoals bij de Gebruikers gegevens) ?
Juist.

Alleen al hieruit volgt dat het niet bij de Gebruikers hoort, en in elk geval bij de Kontaktpersonen mag.

Omdat webshop gebruikers redelijk anoniem zijn, en zeker geen Users (Gebruikers) als zodanig in Profit zijn, terwijl deze wel behoren in te loggen omdat ze uiteindelijk helemaal zo anoniem niet zijn (de gebruiker werkt bij een bestaande klant), en deze "gebruiker" emails toegezonden kunnen worden (Orderbevestiging, Pakbon, Faktuur), aangevuld met het gegeven dat zo'n gebruiker toch redelijk 1 op 1 is met een Kontaktpersoon zoals je die bij een Relatie zou definiëren, is het dus wederom juist dat de email gegevens bij de Kontaktpersoon zijn geregistreerd. Sterker, dat waren ze al redelijk eeuwig, om e.e.a. vanuit Profiit-Kontakt/-Mail te kunnen gebruiken.

Omdat er omwille van het laatstgenoemde domweg geen andere plaats te bepalen *is* (met als uitgangspunt dat de Kontaktpersonen zelf goed genormaliseerd zouden zijn opgezet (wat *niet* het geval is !), is de Kontaktpersoon de enige juist plaats, bepaald uit normalisatie.

Als je dan verder nog iets wilt als "ik als User in Profit wil iemand een Inkooporder emailen", dan is die "ik" helaas niets anders als een User (Gebruiker) die (wederom genormaliseerd) toevallig 1:1 overeenkomt met een Kontaktpersoon bij een Relatie (in mijn geval User PS bij Relatie Heart). Merk op dat dit niets anders is als een Debiteur die 1:1 tevens als Relatie is gedefinieerd, met weliswaar het verschil dat de Debiteur technisch niet zonder de relatie kan (funktioneel ook niet) terwijl de User technisch wel zonder de Kontaktpersoon kan (omdat dit funktioneel ook kan, zolang de betreffende gegevens maar niet zijn benodigd, en welke gegevens onmiddellijk nodig zijn bij aanwezigheid van Profit-Kontakt.

Wat er nu mis gaat met "personeelsnummers" kan ik niet vertellen (je legt immers niets uit), maar jullie zullen het personeel wel een Userid "ABC" hebben gegeven, met personeelsnummer "123". EN DIT IS ONJUIST.
Dit is al onjuist omdat het systseem nu niet zonder maatwerk kan bepalen dat User ABC dezelfde is als Kontaktpersoon 123, terwijl het systeem zoals het is erop anticipeert dat (andersom gezien) Kontaktpersoon ABC (bij bedrijf ADP = Bedrijfs-ID) wel de persoon zal zijn die achter het scherm zit met Userid ABC.

Mocht je nu enigszins in verwarring zijn en niet meer goed weten hoe de AMBI module (uit het hoofd) S4 in elkaar zat : De belangrijkste basis is hier het gegeven dat een niet-User een email gestuurd moet kunnen worden (da's logisch), terwijl diezelfde persoon als wel-user ook een email moet kunnen sturen. Er is geen verschil met beide gegevens groepen, en dus horen die in 1 entiteit (anders zou er pure redundantie volgen).

Zoiets ?

[mdekraa]

Kan ik helemaal volgen, mijn probleem is alleen dat toen we (in overleg met "jouw" adviseur) de klachtenmodule hebben opgezet (ver voor webshop volgens mij) er gekozen is om het personeelsnummer te gebruiken bij de ad medewerkers als zijnde contactpersonen van ADPROD-relatie.

Nu kom ik er dus achter dat dat dus qua insteek formeel niet zo slim is, immers mijn persoontje met Personeelsnummer 051 (ja zo lang zit ik al bij deze baas) heeft totaal geen referentie naar de inlog-user MK

Dus hoe los ik dat nu op ?

Kan ik middels een changekey dat oplossen of moet alles toch dubbel (puur redundant)?

Ik denk dat ik het sneller oplos door Active directory koppeling met onze exchange te controleren, dan is er ook geen autheticatie nodig...

[Peter Stordiau]

De athenticatie was Robert z'n inbreng, maar m.i. gaat het daar niet om.
De programmatuur kijkt domweg naar de Kontaktpersoon gegevens met ID van de user. Als ik hiér nu geen gelijk in heb is het een ander verhaal.
-> Wie ?

ChangeKey zal wel niet werken als je dit als eerste probeert met de Kontaktpersonen. Dus wees op je hoede als je dat pad op wilt.

ver voor webshop volgens mij

Klopt. Maar ik denk dat het niet dit is wat je parten speelt. Zie mijn normalisatie verhaaltje aan het eind. Het gaat om het "algemeen" moeten kunnen addresseren van personen bij bedrijven, en dan kom je toch echt op de Kontaktpersonen uit ...
Dat iemand personeelsnummers adviseert in plaats van userids was in de betreffende (!) context wellicht niet onjuist. Immers, je moet er maar op zien te komen dat waar je (stel) 50 mensen personeel hebt waarvan 10 gebruikers, dat je iets als ene userid moet gebruiken voor het kontaktpersoon id. Het is ook niet formeel natuurlijk, zie ook het aangegeven verschil in het normalisatie verhaaltje. Dus, in het datamodel zou het niet staan, en het wordt procesmatig opgelost.

Uit het laatste volgt ook meteen de formele oplossing : een entiteit waarin je de email gegevens kwijt kan, plus verwijzingen vanuit alle plaatsen waar dit kan optreden. Dus Kontaktpersonen, Userids, en ook Adresgegevens (wat momenteel eveneens procesmatig is opgelost). Word je daar blij van ? tuurlijk niet. Je zit je het schompes te registreren, en nu werkt het ook. Maar ja -en inderdaad- zien (van uit logika) dat het zo moet kan je niet.
De "adviseur" is dan ook niet veel aan te rekenen, net zoals je het ons niet echt mag aanrekenen dat we het niet "slim" hebben opgelost. Immers, het is juist wel slim, maar past intussen niet in jouw plaatje.

Alles bij elkaar had dit de volgorde moeten zijn (niet dat dat prakrijk is, maar voor de lol toch wel) :
Hé, we hebben personeel. Mooi, die nemen we op bij de Kontaktpersonen van ons Bedrijds-id (pas op, want ook Bedrijfs-id is er zo één, waar immers niets 1zegt dat het wel handig is als deze Relatie (ja ja) overeenkomt met het Bedrijfs-id terwijl wel (heel) veel programmatuur ook daarop anticipeert. Vervolgens : hé we hebben ook users. Laten we het ID daarvan maar gelijk houden aan het ID van die Kontaktpersonen. Deze volgorde is juist, maar niet hanteerbaar (omdat je users moet hebbe om Kontaktpersonen in te kunnen vullen).

Om een lang verhaal niet nog langer te maken : voeg gewoon die Kontaktpersonen even opnieuw toe.

-> Wie ?

Maar laten we deze niet vergeten. Dus graag even een konfirmatie.

[Robert Hekkers]

De programmatuur kijkt domweg naar de Kontaktpersoon gegevens met ID van de user. Als ik hiér nu geen gelijk in heb is het een ander verhaal.
-> Wie ?

Dit klopt inderdaad.

[Peter Stordiau]

Dank je Robert.

Dan zou ik inderdaad domweg de Kontaktpersonen toevoegen. En ja, de oude laten staan.
Ik weet niet of dat is te overleven ? (denk aan Kontakten en Kontakt Deelnemers).

[mdekraa]

ga ik zo doen (dubbel dus)

mk