This topic contains 15 replies, has 3 voices, and was last updated by admin 8 years, 1 month ago.
-
AuthorPosts
-
September 28, 2016 at 1:26 pm #73292
MattMy calendar is server side and I’m using SoSimple in Web Direct.
When I’m working with events, $event_type doesn’t seem to be completely implemented. In the action script, $event_type = “new” or $event_type = “edit” are passed and I can manipulate those events. However, the other two, ‘Open’ and ‘Delete’ do not fire at all.
When opening an event the ‘Open’ variable is not passed to the Action Script, nor is any other value for $event_type. However, if you use the save button after opening an event in the SoS web view, it will fire the ‘edit’ variable correctly.
Deleting an event also does not pass the ‘delete’ variable. In the calendar the event text is struck out then the entire event vanishes (is deleted) until the calendar is refreshed and then the event reappears again without modification.
The scripts in the downloaded SoS solution use the variables ‘new, edit, open, delete’ in all lower case. However, your docs on the web show those variables capitalized. Trying both ways it still doesn’t work.
I need to have that Delete button as an option for my users. Any thoughts?
Thanks,
Matt -
September 29, 2016 at 1:55 pm #73293
Hi Matt –
The “Open” event type only runs client-side, since the server is only notified when the event is sent back to the server.
We also verified to make sure that the “delete” event type is also being sent – it is. We did this by creating a logging mechanism – go to neutral table, create a new record, and set a field to $event_type, then go back to the original layout. When we did this, we got the result “delete”.
I suspect there is something else wrong with your script that is causing it to fail. If you run into an error in the script, the script will stop and you will see the results you describe. It sounds like your script is stopping the event from being deleted, so it shows back up again when the calendar is refreshed.
This is why server-side scripting is such a pain – there’s not real interface to see errors unless you carefully catch for them and report them somewhere. Sometimes we’ll do this with a log the way I described above, sometimes we’ll send out an email via SMTP to report status or errors when we’re running server-side.
-
October 3, 2016 at 9:46 am #73306
MattHey Ken,
Yes, server side scripting is awful. I set my action script to send me an email based on each $event_type being sent, see the code snippet below. Edit and New fire but Delete does not. I understand your ‘Open’ explanation. I don’t think my script could be simpler than that. What am I missing?
If [ LeftWords (Get ( ApplicationVersion );1) = “Web” ]
# ##### SERVER-SIDE #####
# — called as a server-side script when “server-side” is enabled.
# — runs in context of the record being created/edited/deleted
# — should return to the context of the same record
# — Our example doesn’t run any extra script steps for server-side scripts, so event changes happen without interference.
If [ $event_type = “new” ]
Send Mail [ Send via SMTP Server ; No dialog ; To: “test@test.com” ; Subject: “new event” ; Message: $event_type ]
Else If [ $event_type = “edit” ]
Send Mail [ Send via SMTP Server ; No dialog ; To: “test@test.com” ; Subject: “edit event” ; Message: $event_type ]
Else If [ $event_type = “open” ]
Send Mail [ Send via SMTP Server ; No dialog ; To: “test@test.com” ; Subject: “open event” ; Message: $event_type ]
Else If [ $event_type = “delete” ]
Send Mail [ Send via SMTP Server ; No dialog ; To: “test@test.com” ; Subject: “delete event” ; Message: $event_type ]
Else
Send Mail [ Send via SMTP Server ; No dialog ; To: “test@test.com” ; Subject: “soS Cal Actions” ; Message: “Error running Action Script. This event wasn’t New, Edited, Opened or Deleted. So what happened?” ]
End If
-
October 3, 2016 at 10:00 am #73307
MattI should add, my process is simple to add an event to the calendar and save it. I get the ‘New event’ email. I edit that event in the calendar and I get the ‘Edit event’ email. I try to delete that event in the calendar and I don’t get any $event_type sent because neither the Delete nor the catch all at the end of my script fired off an email.
-
October 3, 2016 at 11:27 am #73308
MattChecking my calendar Settings, I’m running 3.43 and it says current version is 3.42.
-
October 3, 2016 at 3:02 pm #73309
To confirm soSIMPLE is doing what’s it’s supposed to be doing, make sure that snippet is at the beginning of the script. You mention “end of my script” and I don’t know if you mean that you run this snippet at the end of your Action script. If that’s the case, something may be happening during the execution of the script that exits the script before this snippet runs.
In fact, it sounds like something is happening before this snippet executes, or else you would at least get the catch-all.
I would simplify your test by sending an email right near the top of the action script that just sends an email with the script parameters as the content of the email.
If it’s still not working, try re-creating your “Options” by clicking “Edit” next to Options, and then clicking “New”.
-
October 4, 2016 at 11:12 am #73311
MattThat chunk of code is pulled straight out of your action script from it’s original position in the action script. Nothing of mine runs before it and the first two Ifs fire.
I was speaking about the Else statement at the end of the snippet I included when I spoke of the ‘end of my script’. I’ll try recreating options.
-
October 4, 2016 at 12:32 pm #73312
MattThis reply has been marked as private. -
October 4, 2016 at 12:46 pm #73313
Thanks for the video.
Assuming they’re just copied & pasted version of each other, however is is possible the SMTP settings for the latter to sendmail steps are wrong. Just to confirm, can you copy a known good sendmail step and put it above the “if” block. In other words, use the same sendmail for all conditions. In the content of the message, include the $event_type.
I’m sure you’ve been very diligent, but I’d like to confirm that its not your script before I look at why the variable is sent our copy of the calendar, but not on yours.
Also, what is the full url to the calendar (private message me)? I’d like to see what the parameters are in case that may have something to do with it.
Thanks
-
October 4, 2016 at 1:37 pm #73314
MattThis reply has been marked as private. -
October 4, 2016 at 2:35 pm #73315
I looked over what you sent. It all looks pretty clean. I don’t see why you’re not getting that variable to pass through, but I see that it’s not passing through.
This may take a little bit of time to troubleshoot on our end. I have a couple of questions that may help:
- If you remove all of the SMTP steps, does the event get deleted (even upon a refresh). You may have to add an exit(true) statement in the web block of that script.
- If you remove your custom fields, does that fix the issue?
- Do you have a Text field defined in Data Source setup?
- This reply was modified 8 years, 1 month ago by admin.
-
October 5, 2016 at 12:27 pm #73316
Sorry Ken, the forums aren’t letting me see your private reply. Can you email it to me please?
-
October 5, 2016 at 2:05 pm #73318
Removing the SMTP steps and custom fields had no effect. I don’t understand what you mean about Text field defined. Which field?
-
October 5, 2016 at 2:46 pm #73319
-
October 5, 2016 at 2:54 pm #73321
-
October 5, 2016 at 11:06 pm #73324
I appreciate all the details and feedback. Thank you.
We’re going to try and reproduce the problem on our server to see why this is happening. I’ll keep you posted.
-
AuthorPosts
You must be logged in to reply to this topic.