शेड्यूल और रद्द करना
`scheduledAt`, `emails.reschedule`, `emails.update` और `emails.cancel`।
बाद में भेजना
message = {from: "[email protected]", to: "[email protected]", subject: "Your September invoice", text: "Invoice attached."} client.emails.send(message, scheduledAt: "PT1H")client.emails.send(message, scheduledAt: Time.utc(2027, 1, 1, 9))client.emails.send(message, scheduledAt: "2027-01-01T09:00:00.000Z")एक Time या DateTime, String के रूप में ISO 8601 क्षण, या PT1H या P2D जैसी अवधि। एक साल आगे तक, अतीत में कभी नहीं। Hash के साथ दिया गया keyword argument पहले बनाए संदेश में फ़ील्ड जोड़ देता है।
Ruby Date 2027-01-01 जैसी सादी तारीख़ के रूप में भेजी जाती है, जिसे API उस दिन की UTC आधी रात पढ़ता है। जब घंटा मायने रखता हो तो Time.utc(2027, 1, 1, 9) जैसा Time पास करें।
खिसकाना और रोकना
message = {from: "[email protected]", to: "[email protected]", subject: "Your September invoice", text: "Invoice attached."} queued = client.emails.send(message, scheduledAt: "PT1H") client.emails.reschedule(queued[:id], Time.now + 86_400)client.emails.cancel(queued[:id])सिर्फ़ queued और scheduled संदेश रोके जा सकते हैं। उससे आगे का कुछ भी OpenEmail::ConflictError raise करता है, क्योंकि उसका कुछ हिस्सा पहले ही किसी के मेलबॉक्स में है। पहले से रद्द संदेश को रद्द करना सफल होता है और कुछ नहीं बदलता।
किसी समय-सीमा में जाने के लिए क्या इंतज़ार कर रहा है यह जानने के लिए status: ["scheduled", "queued"] और scheduled_from: तथा scheduled_to: के साथ सूची लें, जैसा ऐप का कैलेंडर करता है।
जाने से पहले उसे बदलना
emails.update ऐसे संदेश को बदलता है जो अभी गया नहीं है: वह कब जाएगा scheduledAt से, वह क्या कहता है subject, html और text से, वह किस पते से जाएगा from से, और किसे जाएगा to, cc और bcc से। इनमें से कोई भी साथ में भेजें, और जो फ़ील्ड आप छोड़ देते हैं वह अपना मान बनाए रखता है। प्राप्तकर्ताओं की सूची सहेजी गई सूची को पूरी तरह बदल देती है। ऐप के कैलेंडर में शेड्यूल किए गए संदेश को संपादित करने पर यही होता है।
updated = client.emails.update( "msg_3f9a1c07d2b84e6a9c5b1f20", subject: "Your September invoice, corrected", to: ["[email protected]", "[email protected]"], scheduledAt: Time.utc(2026, 10, 5, 8)) puts updated[:status], updated[:subject], updated[:scheduledAt]from की जाँच वैसे ही होती है जैसे send पर, इसलिए यह ऐसा पता होना चाहिए जिससे कुंजी भेज सकती है। जो संदेश स्वीकार होते समय अनूदित हुआ वह अपने स्वीकृत शब्द बनाए रखता है, इसलिए उस पर नया subject, html या text 409 translation_locked है, और जो शेड्यूल होने से पहले एन्क्रिप्ट हुआ वह अपने शब्द और प्राप्तकर्ता बनाए रखता है। ऐसे संदेशों को रद्द करें और इसकी जगह फिर से भेजें।
इसके बजाय एक undo खिड़की
message = {from: "[email protected]", to: "[email protected]", subject: "Your September invoice", text: "Invoice attached."} held = client.emails.send(message, cancellableForSeconds: 30) puts held[:status], held[:cancellableUntil]निर्धारित संदेश तो जाने तक वैसे भी रद्द किया जा सकता है, इसलिए दोनों को मिलाया नहीं जा सकता और सर्वर इसे अस्वीकार करता है। तत्काल संदेश पर undo-send खिड़की के लिए इसी का उपयोग करें।
पैरामीटर: निर्धारण
scheduledAtTime, DateTime or String- कब भेजना है, `emails.send` पर: एक Time या DateTime, String के रूप में ISO 8601 क्षण, या `PT1H` या `P2D` जैसी अवधि। Time या DateTime UTC क्षण के रूप में भेजा जाता है, String जैसी है वैसी, और Ruby Date सादी तारीख़ के रूप में जिसका मतलब UTC आधी रात है। भविष्य में कम से कम एक सेकंड और अधिकतम 365 दिन आगे, और किसी भी सीमा को पार करना `scheduledAt` पर `validation_error` है, और सहज भाषा स्वीकार नहीं की जाती, क्योंकि “अगला मंगलवार” को ग़लत समझने से संदेश ऐसे समय पर चला जाता है जिसे वापस नहीं लिया जा सकता।
cancellableForSecondsInteger- “तुरंत” वाले send पर undo-send विंडो: 0 से 900 तक का एक Integer, डिफ़ॉल्ट 0। 0 से ऊपर का कोई भी मान `scheduledAt` के साथ अस्वीकार होता है, जो जाने तक पहले से ही रद्द किया जा सकता है, और इस तरह रोका गया संदेश `scheduled` के बजाय `queued` पर रहता है। यह छोटी देरी वाली वही टालने की प्रणाली है।
idStringआवश्यक- `msg_` id, और `emails.cancel`, `emails.reschedule` तथा `emails.update` का पहला argument। इन्हें अपने किसी scope के बजाय `emails:send` चाहिए, और ये id को कुंजी के अपने वर्कस्पेस में खोजते हैं, इसलिए किसी दूसरे वर्कस्पेस की id ठीक उसी तरह `not_found_error` है जैसे कभी न रही id।
scheduled_atTime, DateTime or Stringआवश्यक- नया समय, `emails.reschedule` के दूसरे argument के रूप में, उन्हीं नियमों से और उसी एक साल की सीमा के भीतर पढ़ा जाता है। `reschedule` सिर्फ़ यही बदलता है, और क्लाइंट और कुछ नहीं भेजता। अवधि उस समय के सापेक्ष होती है जब “सर्वर” उसे पढ़ता है, इसलिए दोबारा आज़माया गया reschedule पहले वाले की तुलना में थोड़ा बाद में पड़ता है: बाद में, पहले कभी नहीं।
api_keyString- तीनों में से किसी भी कॉल पर क्लाइंट की कुंजी के बजाय इस कुंजी से काम करता है।
प्रतिक्रिया
cancel, reschedule और update हर एक पूरा संदेश Symbol कुंजियों वाले Hash के रूप में लौटाते हैं।
objectString- हमेशा `email`। ये कॉल किसी पावती के बजाय पूरे संदेश के साथ जवाब देती हैं, इसलिए क्या बदला यह देखने के लिए कुछ भी दोबारा नहीं लाना पड़ता। `emails.send` यही आकार लौटाता है, साथ में `replayed`।
idString- `msg_` हैंडल। संदेश के पूरे जीवनकाल में स्थिर, और वही id जो उस पर हर दूसरी कॉल लेती है।
statusString- रद्द करने के बाद `cancelled` और reschedule के बाद `scheduled`, उस संदेश के लिए भी जो सिर्फ़ undo विंडो के पीछे `queued` था, जिसे reschedule एक असली शेड्यूल में बदल देता है। सिर्फ़ `queued` और `scheduled` संदेश खिसकाए या रोके जा सकते हैं। उससे आगे का कुछ भी `email_not_cancellable` कोड वाला `conflict_error` है, क्योंकि उसका कुछ हिस्सा पहले ही किसी के मेलबॉक्स में है।
scheduledAtString or nil- वह ISO 8601 क्षण जब संदेश को भेजा जाना है। undo विंडो और `scheduledAt` वाले send दोनों के लिए सेट होता है, क्योंकि दोनों एक ही प्रणाली हैं, और सादे तुरंत वाले send पर nil।
cancellableUntilString or nil- जब रद्द करना काम करना बंद कर देता है, जो टालने वाले दोनों रास्तों पर `scheduledAt` वाला ही क्षण है। तुरंत वाले send पर nil, जो कॉल लौटने तक जा चुका होता है।
sentAtString or nil- जब संदेश असल में निकला। इंतज़ार के दौरान nil, और रद्द संदेश पर हमेशा nil।
messageIdString or nil- RFC 5322 Message-ID, जो MIME बनने तक nil है, इसलिए जिस संदेश पर ये कॉल काम कर सकती हैं उस पर हमेशा nil। यह API से बात करने का ज़रिया नहीं है, और न ही बाद का कोई bounce इसके साथ लौटता है: भेजने वाली सेवा बाहर जाते समय हेडर दोबारा लिखती है।
threadIdString or nil- वह थ्रेड जिसका यह संदेश हिस्सा है, रिक्वेस्ट से लिया गया और भेजने के बाद transport जो बताए उससे दोबारा लिखा गया। जब यह जवाब न हो तो nil।
transportString or nil- बाइट्स कैसे निकले, और भेजे जाने तक nil, इसलिए हर उस संदेश पर nil जिसे रद्द करना या reschedule लौटा सकता है। test मोड वाला send `test` दर्ज करता है, और ऐसा transport भी दिख सकता है जिसका नाम यह gem अभी नहीं लेता, इसलिए अज्ञात मान को error नहीं, जानकारी मानें।
attemptsInteger- भेजने की प्रक्रिया ने इस पंक्ति पर कितनी बार दावा किया। यह सफल send से नहीं, हर दावे के साथ बढ़ता है, और जो अभी इंतज़ार में है उसके लिए 0 है।
lastErrorString or nil- संदेश पर दर्ज आख़िरी विफलता, जब तक कुछ विफल न हुआ हो तब तक nil। जिस टाले गए send का जॉब queue में नहीं डाला जा सका, वह यहाँ `Could not schedule: …` के रूप में लिखा जाता है और `failed` पर पहुँचा दिया जाता है, और यही एकमात्र तरीका है जिससे शेड्यूल किया गया संदेश बिना किसी के माँगे रद्द करने योग्य नहीं रहता।
fromString- वह पता जिससे संदेश को बाहर जाने की अनुमति मिली: भेजा गया `from`, सादे और छोटे अक्षरों में सहेजा गया। कोई भी display name यहाँ हटा दिया जाता है, क्योंकि `emails.list` का `from:` फ़िल्टर बराबरी पर तुलना करता है।