September 19, 2016 at 10:25 am
I have a question about development. We have a .net app that counts student truant days.
On UI, we'd like when users dismiss a case, it will auto populated today's date as default case closed date. But they can also change the date to an earlier or possibly later date.
The problem is that at background we have a nightly process that creates student truancy cases by count their days of truant, we don't want to count those days prior to closed date for new cases.
My question is how we should handle this for UI logic, should we do those in .net code, when click dismiss a case, it will populate the case closed date as default date, and give them a chance also to change the date. and then make the case read only.
I don't want them to change the closed date at any other time, for that could mess up the calculation of new case at the backdoor nightly process.
Or should we add a trigger for the TruancyCase table?
what is the best way to do? thanks
September 19, 2016 at 10:37 am
It seems like you have two things here. The background process and how this calculates, which I'm not sure what that means for your UI logic or tracking the date. How is that related?
In terms of changing the date, I think you can do this anywhere, it just depends on what the flow is. It seems that since this is based on a user's action, you either need to handle this in the UI, or submit this as a parameter to the back end to note something is dismissed. I'd do both, since I want a user action in the UI, but I want to be sure any process, whether the UI, ETL, or anything follows the same rules.
For preventing change later, what is another time? If I get behind and don't look at new cases until next week, can I still set a date? How does a back end know a case is looked at later? I think you need the UI to manage the prevention of changing the date later, unless you can define what later is.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply