Yeni Kayıt sonrası bildirim maili

Question

Merhaba arkadaşlar,
2-3 Yıl zorunlu bir aradan sonra tekrar döndüm sahalara ama paslanmışım biraz :)
bir konuda yardımınıza ihtiyacım var.

Ekte örneği olduğu şekilde standart bir anasayfa - sipariş sayfası - sipariş listesi çalışmasında,
her yeni sipariş girildiğinde belirlediğim bir mail adresine bildirim maili göndermek istiyorum.
Ama bunu "Kayıt" butonu koyup her bastığında mail göndermesi şeklinde değil (unuturlar basmayı)
Yeni sipariş açıldıktan sonra kullanıcı Anasayfaya veya Sipariş Listesine döndüğünde fark ettirmeden veya kullanıcının insiyatifine bıraktırmadan göndermek istiyorum.

"Yeni sipariş" butonlarına Last Record ID sini ve AccountName alan bir script yaptım.
Çıkış için kullanılacak Anasayfa ve Listele butonlarına da Record ID ile Account name leri kontrol eden bir script yaptım.

Ancak burada dikkat etmek gereken şu, Kullanıcı yeni sipariş açtığında, Anasayfa veya Liste butonlarına basmadan sipariş sayfasında bekleyebilir, bu durumda da mail göndermek istiyorum.

Bu arada kullanıcı yeni sipariş açar iken başka bir kullanıcı da başka bir sipariş açabilir.
Fikirleriniz ve yardımlarınız için teşekkürler.

http://filemakerturk.com/?qa=blob&qa_blobid=2142826655896632179
 

 

Comments

Hoşgeldin okan bayadır sesin çıkmıyor.

Answer 1

Merhabalar,

Bir oneridede ben bulunayim.

Faturalar bolumunden cikisi sadece bir button uzerinden gecisine izin verecek sekilde duzenleyiniz.

Fatura tablosu icerisinde faturalarin acildigini tutan yeni bir Timestamp alan aciniz. buna CreationTimestamp ismini verebilirsiniz

Fatura tablosu icerisinde recordlarin duzenlenme tarigini tutan yani "ModificationTimestamp" Timestamp alani ekleyiniz.

Ayni Tablo icerisinde mailin MailgonderildiTimestamp Timestampi gireceginiz bir baska "Timestamp" alani alani ekleyiniz. Bu alani maili gonderdiginiz an Get ( CurrentTimestamp ) ile set edeceksiniz.

Faturalar alanindan cikis icin buttona tiklandiginda assagidaki kontrol ve islemleri yapiniz.

 

----------------------------
If (Fatura::CreationTimestamp = Fatura::ModificationTimestamp ;

Mail gonderme,  cunki kayit acilmis ama islem yapilmamis
)
----------------------------

 

----------------------------
If (Fatura::CreationTimestamp < Fatura::ModificationTimestamp ;

if ( Fatura::MailgonderildiTimestamp ≠ Fatura::ModificationTimestamp ;

Maili gonder

Set Field => Fatura::MailgonderildiTimestamp = Get(CurrentTimeStamp)

;

Mail gonderme,  cunki son gonderilen mailden sonra duzenlenme yapilmamis
)
----------------------------

 

Ornek dosya:

http://filemakerturk.com/?qa=blob&qa_blobid=15487927966691264869

Comments

çözüm güzel ancak siparişi açıyorlar ancak kalemleri sonradan dolduruyorlar,
siparişe 2 kalem ekleyip 10 dakika sonra 2 kalem daha ekleniyor.
sipariş açıp, çıkışa hiç basmadan öyle saatlerce bekleyen de var, serverdan disconnect olan da var. Çarpıya basıp direkt kapatan var, PC si resetlenen var.
onun için sipariş Listesine serverdan çalışacak bir script düşünüyorum,
5-10 dakikada bir sipariş sayısını/ID sini kontrol edecek, değişiklik var ise yeni açılan kayıtlar için tek tek mail atacak gibi.

Answer 2

 Tekrar hoşgeldiniz.

 

Anasayfa veya Liste butonlarına basmadan sipariş sayfasında bekleyebilir

Ancak, aynı zamanda kullanıcı siparişe satır ekleme esnasında da bekleyebilir,yani aslında sipariş tamamlanmadan....  (bu durumda,yani siparişin sonucu belli olmadan mail atmak istemiyorsunuz sanırım.)

 

Dolayısı ile, ya kullanıcıyı "siparişi tamamla" vs gibi bir buton ile yönlendirip,bu butonla smtp mail atacaksınız, (buton,portalın toplamını number bir alana yazar,bir sonraki adımda mail atar.sipariş toplamını otomatik aldırmayın ki kullanıcı tamamlaması gerektiğini düşünsün.) ya da çıkış butonlarından birinin çalışmasını bekleyeceksiniz...

Comments

Siparişi tamamla, Kaydet, Bildir gibi butonlar mevcut ancak kullanmıyorlar, unutabiliyorlar.. Bunun önüne geçmek için yeni bir çozüm arıyorum.

Answer 3

merhaba, on-commit triger'ını kullanarak kaydettiğini anlayabilirsiniz. ancak commit sonrası yeni değişiklik yapıldığında on-commit tekrar çalışır. bazı durumlarda, kaydı doldurmayı bitirmeden boş bir yere tıkladığında, kayıt yarımken de çalışabilir.

 

benim önerim kaydet ve vazgeç düğmeleri ile kaydın tamamlandığını kullanıcının karar vermesi. vazgeç'e tıklarsa işlem hiç gerçekleşmemiş olacak. kaydet dediğinizde ise scriptlerle istediğiniz kontrolü yapabileceksiniz.

 

bunun için filemakerdestek.com'da bir makale yayınlamıştık, şu adresten ulaşabilirsiniz: http://www.filemakerdestek.com/2017/06/21/scriptler-ile-kaydet-vazgec-kontrolu/

Comments

Kullanıcıdan insiyatifi tamamen almak istiyorum.
Sipariş Listesine serverdan çalışacak bir script düşünüyorum,
5-10 dakikada bir sipariş sayısını/ID sini kontrol edecek, değişiklik var ise yeni açılan kayıtlar için tek tek mail atacak.

---

İnsayitifi tamamen alamazsınız :)
tam kayıt yaparken farketti ki o kayıt zaten eklenmişti, vazgeç'e tıklayıp yoluna devam etmesi genelde gerekir.

yada şöyle bir seneryo düşünün. formu doldurdu, kaydet vazgeç olmadığı (otomatik kaydettiğini düşündüğü) için kayıttan çıkmadan (commit işlemi yapılmadan) ekranın başından kalklı, 15 dakika sorna geldiğinde bağlantı gitti ve dosyaya bağlanamadı. Kaydı kaydettiğini düşünüyor (bu konuda yemin bile eder) ama commit işlemi yapılmadığı için FM Server'den kayıttan haberi yok. Sisteme çamur atabilir, kaydı girmiştim sistem sildi diye :/


Özellikle kullanıcı insiyatifini kısıtlamak için kaydet/vazgeç'in mühim olduğunu düşünüyorum. Bu sayede scriptlerle veri doğrulaması gibi işlemlerde çok daha esnek olabilirsiniz.

Answer 4

Interface-Data yaklaşımını da ben önereyim.

Data tablosunda değişiklik yapacağınız kaydı kullanıcıya global alanlardan oluşan bir Interface tablosuna taşıdıktan sonra gösterin. Ve tabii Kaydet ve Vazgeç seçiminde göre Interface'ten tekrar Data'yı manipüle etmeniz gerekecektir...

Comments

Bu yaklaşımda interface'i basit mi tutmamız lazım? Mesela interfacede bir portal varsa?

---

Osman hocam, ben en başta interface tablosunda her bir alan kategorisi için çokça global alan yaratıyorum. ( TextEntry01, TextEntry02 Number Entry01, DateEntry01... ). Kullanıcı data tablosunda veya portalda bir kaydı düzenlemek istediğinde ligili kaydı bu interface tablosuna taşıyorum.

İster menuden, liste görünümünden veya portal'den nerden gelirse gelsin her seferinde kayıt ile ilgili kullanıcıya her bir katmanda daha çok bilgi ve seçenek sunuyorum. Sadece en son düzenleme ekranında ( tabii ki interface tablosu ) kullanıcının kayıt alanlarına erişim izni veriyorum. Gavurlar bu tasarım tekniğine "Progressive Disclosure" diyor.

Ayrıca bu interface-data yaklaşımı ile çok kullanıcılı sistemlerde record-locking sorunu yaşamazsınız!...

---

Recep abi hala ikna olmadım :)

"Progressive Disclosure" doğrudan "Interface-Data" yaklaşımınla ilgili değil bence. Eski usül kullanımda da çok güzel "Progressive Disclosure" uygulamaları yapılabilir/yapılıyor. Gavurlar usebility konularına hakikaten kafa yoruyor, önemli.

"Interface-Data" yaklaşımının en uygun kullanımı sanıyorum "pro" seviyesinde filemaker kullananların bitmiş ürünleri için olabilir. Aksi halde filemaker'ın kolaylığından uzaklaşıyor bir miktar.

Basit (tablo alan sayısı sınırlı) uygulamalarda nispeten uygulanabilir, ama karmaşıklık arttıkça geliştirme ve bakım maliyetleri artacaktır.

Record locking kötü bir şey değil. Aynı sorunun tam tersi "Interface-Data" mantığındaki da "record-conflict" olarak karşımıza çıkacak.

Ben hala  "Trigerred Edit Layout w/ Save&Cancel" yaklaşımını savunuyorum. Mümkün olan yerlerde "Progressive Disclosure" hayır demem :)

---

Terimler kafamızı karşıştırmasın hocam. Çözüme örnek vermek için yazdım.
 
Büyük projelerimde datanın değişiklik yapılacağı ekranlarda bu mantıkta hareket ediyorum.
Bakımıydı, kullanım zorluğu vb. bana biraz şehir efsanesini çağrıştıryor.
İstenilen datayı optimimum güvenlik ve seviyede basit bir copy-paste işlemi gibi istediğim yerle alış-verişte bulunabiliyorum. Record conflict'i bir flag ile kolaylıkla yönetebiliyorum. Yani bugünün modern form based web ve api dünyasındaki gibi bir şablonla rahatım keyfim yerinde. :) Yoksa geçen ben de bir kişisel kütüphane projesinde seninkine benzer bir çözüm uygulamıştım...