Document als (bijv) mail teruggeven

5 reacties / 0 nieuw
Anoniem
Document als (bijv) mail teruggeven

Tijdens de werkgroep bijeenkomst op 17 juni is deze functionaliteit voorgesteld, maar niet voldoende uitgewerkt om een volledig beeld te hebben op basis waarvan we direct kunnen bepalen of dit haalbaar is om mee te nemen en wat hieronder verstaand wordt.

We moeten onder andere de volgende zaken helder krijgen: 

  1. Hoe verhoudt zich dit tot de 'vervolgacties'? Met andere woorden: alleen een mail als bestand of ook verzenden?
  2. Wat is het 'documentformaat' (MimeType) van e-mail?
  3. Hoe gaan we om met het feit dat e-mail andere input vereist dan bijvoorbeeld een RTF/Word/PDF document:
  4. Hoe wordt die input gevraagd?
  5. Weet de DCV dat iets een mail moet worden? Of bepaalt deze het zelf? Hoe borgen we dat
  6. En grijpen we dit ook aan om meer metadata velden te kunnen vullen van andere bestandsformaten?
  7. Hoe belangrijk is dit item voor u (business case voor potentiële klanten/concrete interesse)?
  8. Kan dit als extensie? Het beeld van KING is van wel. 

Wij zien uw input omtrent dit onderwerp graag tegemoet. Item staat op de lijst als [DCR-3]. 

Edwin Geerling

Welke input wordt er bedoeld met punt 3? Zaken zoals een e-mailadres en dergelijke? Punt 3.3 begrijp ik niet helemaal, welke metadata velden moeten we dan aan denken?

Joost Wijnings

Ik dacht aan minimaal TO / FROM / SUBJECT / CC / BCC, maar er zou nog meer bedacht kunnen worden voor specifieke mailservers. Dus hoe ver willen we daarin gaan?

Johannes Battjes

Roxit: Hoe verhoudt zich dit tot de 'vervolgacties'? Met andere woorden: alleen een mail als bestand of ook verzenden? = Volgens Roxit kan verzenden ook vanuit de DcV (in combinatie met email client zoals Outlook) en hoeft dit niet per se vanuit DcA. Als DcA de email wel verstuurt, zou in het bericht verstrekdocumentcreatieresultaat aan DcV de vezendinformatie toegevoegd moeten worden zodat DcV weet aan wie het bericht verstuurd is. Wat is het 'documentformaat' (MimeType) van e-mail? = Ondersteuning van tenminste .msg zou handig zijn. Dit kan in onze ogen nu al in het veld formaat teruggegeven worden. Hoe gaan we om met het feit dat e-mail andere input vereist dan bijvoorbeeld een RTF/Word/PDF document? = kunnen we emailsjablonen niet net zo behandelen als andere sjablonen en het aan DcA overlaten om de juiste inputvelden aan te bieden aan gebruikers? Dan hoeft het berichtenverkeer hiervoor wellicht niet aangepast te worden. Hoe belangrijk is dit item voor u (business case voor potentiële klanten/concrete interesse)? = Belangrijk. Wij moeten nu misschien zelf email editors bouwen, en dat is zonde. Kan dit als extensie? Het beeld van KING is van wel. = Ja, maar wellicht is dit niet nodig. Voor zover wij zien kun je met de huidige standaard een heel eind komen. BCC, CC emailadressen kunnen wellicht uit de contactgegevens van betrokkenen bij de zaak gehaald worden door DcA en in het juiste veld geplaatst?

Michiel Verhoef

Dit is uitgebreid besproken tijdens de bijeenkomst op 11 november 2014. De use case was echter niet volledig duidelijk, daarom graag input op onder andere de volgende vragen:

  1. Wat is de gedeelde functionele behoefte? Uitgesplitst naar wat bepaal je in de DCV en wat in de DCA?
  2. Maakt DCA alleen de body of de hele message?
  3. Wat is de rol van een e-mail?
  4. Hoe moet omgegaan worden met het samenstellen van een e-mail?
  5. Gebruik van gegevens als to, cc en bcc in de mail body. Denk aan vermelden van de cc in de tekst.
  6. Moeten deze gegevens dan ook weer teruggestuurd worden of beschikt de DCV hier zelf nog over, wanneer de DCV de mail gaat versturen.
  7. Wie verstuurt de e-mail, de DCA of de DCV? etc. De visie van iWriter is: e-mail in fatsoenlijke huisstijl versturen, op gemakkelijke wijze. Is dit de algehele visie? Of is het genereren van een e-mail body die door de gebruiker zelf opgemaakt en verstuurd wordt voldoende?