I would like to put an expiration time in my processes made in the processmaker v3.5.7 community,
I see that I can only set the time but even if it expires, they can be done to continue.
What I want to do is that when it expires they cannot be modified or sent to continue with that process.
Thanks in advance.
I hope to be able to send the process to several users, but when someone leaves time without reviewing or completing it, it may expire, it will be visible but not modifiable.
Never done anything similar but it seems to me that you probably need to use a Boundary Timer Event in your task and make it so that if the timer expires, the process continues even if the user has not completed his task.
You can read about it here
Related
In the comments of this answer I was having a discussion about backgroundTasks which eventually led to:
Use backgroundTasks for anything that isn't related to download/upload. For upload/download use NSURLSessions's backgroundSessions. Then I made another comment asking why not use background Sessions for all types of requests and was told:
For regular REST calls, background sessions are much less convenient,
and generally not what you'd want. They're not a general purpose tool
for every request; they're for performing uploads and downloads.
What makes background sessions less convenient for REST calls? Sometimes you may have slow internet with a huge chunk of data. Wouldn't it be a convenience to make sure all your data submissions go through?
I'm not sure but if you're doing something like a bank transaction, you wouldn't want to use a backgroundSession. Because you want the user to know of the decision before they leave. User should never the assumption that they could leave app and app would continue to work as should. Nor they should be under the impression that they can resume (by a downloadTaskWithUrl).
What happens if for some reason the user makes a $2000 transaction and hits the button expecting the transaction to go through but it doesn't. The next time the user comes back to the screen they could either be logged out due to security reasons and never know about it or stay logged in but they see an alert that the transaction failed. And now they're like "Oh no my daughter needed $2000 urgently. She must be still waiting for the money!".
You don't want to allow users to have bad expectations*. Rather you want users to take FULL responsibility themselves and not hit home screen and wait for the success/failure. So once the user clicks on submit transfer he'd wait for it to either get success and move on or see failure and wait and investigate the reason his transaction didn't go through.
You usually convey the possibility of failure through an spinner/animation and the actual outcome (failure or success) through an alert.
*Bad expectation is: Every time I hit the the submit transfer button it will go through and there's 0 chance of failure and no need for you to wait and see it go through.
I have a timer project requirement in my web server. Some effects done by clients operations at the server needs to be reset after sometime the had occurred. To do this, I intend to use erlang:start_timer/3 function to send a reset message to a process that does the resetting for each effects. This is ok with few client's operations coming in. The question is, does erlang timer scales very well as the number of current effects to time for reset increases?
Don't guess, don't ask, try it and measure. Nobody know your use case and requirements better than you. Is it for profit? Then you are paid for it. Is it as a hobby, then be used to it. It is an integral part of your job.
I want to deploy managed iOS devices to employees of the company, and the app they will use will timestamp data that will be recorded locally, then forwarded. I need those timestamps to be correct, so I must prevent the user from adjusting the time on the device, recording a value, then resetting the date and time. Date and time will be configured to come from the network automatically, but the device may not have network connectivity at all times (otherwise I would just read network time every time a data value is recorded). I haven't seen an option in Apple Configurator to prevent changing the date and time, so is there some other way to do this?
You won't be able to prevent a user either changing their clock or just hitting your API directly as other commentators have posted. These are two separate issues and can be solved by having a local time that you control on the device and by generating a hashed key of what you send to the server.
Local Time on Device:
To start, make an API call when you start the app which sends back a timestamp from the server; this is your 'actual time'. Now store this on the device and run a timer which uses a phone uptime function (not mach_absolute_time() or CACurrentMediaTime() - these get weird when your phone is in standby mode) and a bit of math to increase that actual time every second. I've written an article on how I did this for one of my apps at (be sure to read the follow up as the original article used CACurrentMediaTime() but that has some bugs). You can periodically make that initial API call (i.e. if the phone goes into the background and comes back again) to make sure that everything is staying accurate but the time should always be correct so long as you don't restart the phone (which should prompt an API call when you next open the app to update the time).
Securing the API:
You now have a guaranteed* accurate time on your device but you still have an issue in that somebody could send the wrong time to your API directly (i.e. not from your device). To counteract this, I would use some form of salt/hash with the data you are sending similar to OAuth. For example, take all of the parameters you are sending, join them together and hash them with a salt only you know and send that generated key as an extra parameter. On your server, you know the hash you are using and the salt so you can rebuild that key and check it with the one that was sent; if they don't match, somebody is trying to play with your timestamp.
*Caveat: A skilled attacked could hi-jack the connection so that any calls to example.com/api/timestamp come from a different machine they have set up which returns the time they want so that the phone is given the wrong time as the starting base. There are ways to prevent this (obfuscation, pairing it with other data, encryption) but that becomes a very open-ended question very quickly so best asked elsewhere. A combination of the above plus a monitor to notice weird times might be the best thing.
There doesn't appear to be any way to accomplish what you're asking for. There doesn't seem to be a way to stop the user from being able to change the time. But beyond that, even if you could prevent them from changing the time, they could let their device battery die, then plug it in and turn it on where they don't have a net connection, and their clock will be wrong until it has a chance to set itself over a network. So even preventing them from changing the time won't guarantee accuracy.
What you could do is require a network connection to record values, so that you can verify the time on a server. If you must allow it to work without a net connection, you could at least always log the current time when the app is brought up and note if the time ever seems to go backwards. You'll know something is up if the timestamp suddenly is earlier than the previous timestamp. You could also do this check perhaps only when they try to record a value. If they record a value that has a timestamp earlier than any previous recorded value, you could reject it, or log the event so that the person can be questioned about it at a later time.
This is also one of those cases where maybe you just have to trust the user not to do this, because there doesn't seem to be a perfect solution to this.
The first thing to note is that the user will always be able to forge messages to your server in order to create incorrect records.
But there are some useful things you can use to at least notice problems. Most of the time the best way to secure this kind of system is to focus on detection, and then publicly discipline anyone who has gone out of their way to circumvent policy. Strong locks are meaningless unless there's a cop who's eventually going to show up and stop you.
Of course you should first assume that any time mistakes are accidental. But just publicly "noticing" that someone's device seems to be "misbehaving" is often enough to make bad behaviors go away.
So what can you do? The first thing is to note the timestamps of things when they show up at the server. Timestamps should always move forward in time. So if you've already seen records from a device for Monday, you should not later receive records for the previous Sunday. The same should be true for your app. You can keep track of when you are terminated in NSUserDefaults (as well as posting this information to the server). You should not generally wake up in the past. If you do, complain to your server.
Watch for UIApplicationSignificantTimeChangeNotification. I believe you'll receive it if the time is manually changed (you'll receive it in several other cases as well, most of them benign). Watch for time moving significantly backwards. Complain to your server.
Pay attention to mach_absolute_time(). This is the time since the device was booted and is not otherwise modifiable by the user without jailbreaking. It's useful for distinguishing between reboots and other events. It's in a weird time unit, but it can be converted to human time as described in QA1398. If the mach time difference is more than an hour greater than the wall clock time, something is weird (DST changes can cause 1 hour). Complain to your sever.
All of these things could be benign. A human will need to investigate and make a decision.
None of these things will ensure that your records are correct if there is a dedicated and skilled attacker involved. As I said, a dedicated and skilled attacker could just send you fake messages. But these things, coupled with monitoring and disciplinary action, make it dangerous for insiders to even experiment with how to beat the system.
You cannot prevent the user from changing time.
Even the time of an Location is adjusted by Apple, and not a real GPS time.
You could look at mach kernel time, which is a relative time.
Compare that to the time when having last network connection.
But this all sounds not reliable.
I have a requirement where I need to know what is the server time at a given point of time in the app. As soon as the app connects to server, the server sends back the time and I am not sure how to update this time.
I thought of using the timers where the method is called every second and and a second is added to server time, so that whenever I ask for server time it is always updated one. But problem with this if we schedule this on main runloop, the run loop may or may not process the timer request if there it is busy.
So how to track the server time?
Thanks
Your server is in a specific time zone correct? Just get the time zone of the server using a request and show the time in that time zone in your app. You can then use a timer to continue updating the time every second.
I suggest getting just the time zone because if you get the server's time, there would be a lag between when the server sends back the response and when you get it - which defeats the whole purpose of getting the time as on the server.
You can't update the iOS system time from your app; there is no API
for that.
iPhone's time is usually very accurate. On iPads, it varies but has improved with iOS 5 to +/- 5 seconds if some form of internet connectivity is available.
If you want to manually connect to a server to synchronize time, you
should do it in a background task.
To compensate for latency, you should make multiple requests and add
the average half of the roundtrip time to the time sent by the server.
However, the question remains: Why do you want to do that anyway?
I have a pending transaction between two Accounts, and after a preset date, if nothing happens, then the transaction should be automatically expired. (I need this expiration to happen in real time, and not when one of the users login to their account).
What would be the best way to create a timer to check against transactions and set their status in near time?
Thank you.
Use a rake task triggered with a cron job, as Abe Petrillo suggests. There is overhead as rake must load up the rails env each time, but if this happens based on date then i guess you just need to run it once a day, in which case the overhead isn't significant.
That cron-in-ruby thing looks kind of overengineered to me.