csabo | Posts: 40

Package Expiration Dates

0 votes
I'm looking for more information on the expiration date. Can you tell me how the date and time is stored on your end? And then what is checked when the expired callback event is sent? I would like to set it to expire today, but I get an error message saying the date must be in the future. Should I be including a time when setting this value? If so, should it be 11:59pm UTC or is it timezone specific? Thanks Colleen

Approved Answer
harishaidary | Posts: 1812

Reply to: Package Expiration Dates

0 votes
Hey Nathan, Setting an expiration date is an optional feature. eSignLive will not set one for you during package creation if you don't specify it. In other words, there is no default expiration date. An expiration date can be set either from the web portal by going in the advanced options or programmatically by adding .ExpiresOn(date) when building your DocumentPackage object. You'll have to do this for every package you create, as there is no default one. Hope this helps!

nhass | Posts: 23

Reply to: Package Expiration Dates

0 votes
Haris Do the Advance Options exist in the sandbox web portal? I can't seem to find them in there. Thanks for the reply. Nathan

harishaidary | Posts: 1812

Reply to: Package Expiration Dates

0 votes
When you login to your sandbox, click on "Send New Package". There, you'll see a "details" and a "advanced options" tab. advanced options If you want to set the expiration date at a later time or you forgot to do it during package creation, you can set it by clicking on the gear icon in your package as shown below:

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
To what precision are you setting the date value? Down to the hour/minute/second or just the date? If just today's date, the time would default to midnight, this morning. Also, the timezone is GMT. So, if you're in say EDT, you're actually something like -4:00 (-5:00 when not daylight savings). So, if you were to put an expiration of less than 4 hours into the future, you'd be putting the expiration date in the past. I have not yet tested setting an expiration for today. I will take a look at that, now and report back.

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
Just a quick update: I was just told that we would be supporting more timezones in a near-future release, 11.2.

csabo | Posts: 40

Reply to: Package Expiration Dates

0 votes
Hi. I have not been passing a time in, so the midnight time makes sense to what we are seeing. We store date/hour/minute/second in our system. I can account for the timezone when the user sets it on our end and convert it to GMT before saving it in your system. So, that's fine. What time is checked when it's expired? GMT midnight, or something else? Thanks Colleen

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
My guess would be GMT midnight on the day that you set, if you do not include a time. I will run a test, tonight and double check that. :)

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
Okay. I had this set up in a Java project already, so I tried it there and I passed my expiration date as today at 1:53pm CDT. Because the date object is created with the offset, when you set this date in eSignLive, even with its timezone being GMT, it still sets exactly as you would expect. My package expired about 13 minutes ago as expected. I'll do a quick test with C# and .NET SDK, but I'll assume it's the same. The only time that this really will be an issue, as far as I've tested previously, is with reminders. If GMT midnight has passed, your "with days until first reminder" setting will be offset by an extra day from your time zone. Hope this helps. I'll let you know on the C# test.

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
With C#, I had to add my offset to the expiration date when creating a DateTime object, like this:
myDocPackage.ExpiryDate = new DateTime(2016, 6, 1, 19, 20, 0); //This was for 2:20pm CDT

csabo | Posts: 40

Reply to: Package Expiration Dates

0 votes
Michael, Thanks for the quick update. I'll give it a try and let you know. Colleen

fevieiraleite | Posts: 42

Reply to: Package Expiration Dates

0 votes
Hi Michael (or anyone from esignlive), my name is Fernando and I work with Colleen. I was having some issues with a package still being available after the expiration date. Upon further investigation, I found out that the package still had the status "SENT" in your system even though the due date was in the past. We are passing the date in the correct format (GMT) and I can see in the package that it's getting updated to the correct time. Looking at my sandbox inbox, the package says: Expiry date: July 7 2016 (31 minutes ago). When filtering by "Expiring Soon", the package still shows up there even though it says it already expired. The package id is be49a1cd-b653-48d9-a3ae-5df495e4d7b0, in case you want to take a look. Any ideas on why this is happening? Thanks, Fernando

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
Hello Fernando, It's still in the inbox or you can actually still access the package from the email that was sent out? I believe that an expired package will still be "sent", but is not accessible to signers that were sent an email that they had documents to sign. Please let me know.

fevieiraleite | Posts: 42

Reply to: Package Expiration Dates

0 votes
Just took a look and now the package says expired. Wondering if it waits until the start of the next hour to update the status. Will try again now and set the expiration date to 5 minutes from now and see what happens.

fevieiraleite | Posts: 42

Reply to: Package Expiration Dates

0 votes
Ok it is now 10 minutes past the Due date and I'm still able to access and sign the package from the email. And to answer your point about the status still being "SENT", I don't think that's how it works because it did change to "EXPIRED" after a while. I think this is an issue where it's taking a while to update the status. My guess would be that it waits until the beginning of the next hour.

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
Interesting. What version of the application are you using? https://sandbox.esignlive.com/ https://sandbox.e-signlive.com/ https://apps.e-signlive.com/ .... etc.

fevieiraleite | Posts: 42

Reply to: Package Expiration Dates

0 votes
https://sandbox.e-signlive.com

fevieiraleite | Posts: 42

Reply to: Package Expiration Dates

0 votes
Just checked and now the package is listed as expired. So it is an hourly check issue. Is there any extra configuration that we can set to change that when creating the package? Thanks, Fernando

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
Nope, there shouldn't be. This sounds like a bug. I will do some testing on my end to make sure and then I'll report it to support to have a ticket created. I'll also check against sandbox.esignlive.com to see if it has the same issue, if I see the same as you in e-signlive.com.

fevieiraleite | Posts: 42

Reply to: Package Expiration Dates

0 votes
Ok thank you for checking on that. Meanwhile, I have another question: Is there a callback method for when a package changes state from Expired to Draft? Would it be the PACKAGE_RESTORE event? Fernando

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
If I had to guess, I'd assume this notification is only made when restoring a package from the Archive or Trash, but I'll look into it. As for the package expiration, packages only expire on the hour. If the UI is showing the expiration at the exact minute that it was set to expire in the code, this is a bug based on the current functionality. Support is investigating this and will file a bug if they see the same. If you need "down-to-the-minute" expiration, we would have to submit an enhancement request to get this functionality. Let me know.

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
Also, when a package expires, it should go to draft. You should receive a package expiry notification at this time, so that should take care of that need. Just not based on the old UI which as you're saying is showing the package expiring at a time in the middle of an hour. The new UI (sandbox.esignlive.com) does not have this issue. If you'd like to get an account on the new sandbox, you can do so by going to the Getting Started page from the navigation above and go to create a sandbox. We are filing a bug for the old UI.

fevieiraleite | Posts: 42

Reply to: Package Expiration Dates

0 votes
What do you mean when a package expires it should go to draft? For me, the status changed to Expired and stayed that way until I changed the due date to a future one. Which is the behavior that I would expect. If it changed automatically to draft mode that could cause some confusion. I was just wondering if there's a callback for when the due date is changed to a future one, thus changing the status from Expired to Draft. I could just automatically change the status on our end, and assume that the status has been changed on yours, but I would prefer getting the callback in order to have consistency between data. Fernando

mwilliams | Posts: 957

Reply to: Package Expiration Dates

0 votes
There seems to be some confusion on what you mean by going to a "draft". A draft is an unsent package. When a package expires (top of the hour, not the minutes you put in - this is the bug we talked about in the old UI), it automatically is deactivated and goes to the DRAFTS folder. If you were to then extend the expiry date to a future point in time, you'd have to update the expiration date and resend it.

fevieiraleite | Posts: 42

Reply to: Package Expiration Dates

0 votes
Ok, let's see if I can convey my message better to you, I apologize if I wasn't clear enough. After a package expires, the status of the package in eSignLive is changed to "EXPIRED", and it sends a notification about the event. I'm verifying this by doing a GET Request on the package and looking at the status attribute. Whenever we get that notification, we change the status of the package in our database as well. After extending the date on the expired package, the eSignLive status changes from "EXPIRED" to "DRAFT". But since we are not getting any notifications, in our database it stays EXPIRED. My question was if there was any notification for this particular case: When a user extends the date of an expired package, thus changing the status to DRAFT. Thanks, Fernando

Hello! Looks like you're enjoying the discussion, but haven't signed up for an account.

When you create an account, we remember exactly what you've read, so you always come right back where you left off