Suggestions for coding an Immutable Timestamp

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestions for coding an Immutable Timestamp

James Newcombe
I have a form that requires an approval step, and requires that the act of approving be timestamped.

The approval takes the form of a set of radio buttons - "Approved", "Not Approved" and "More Information Required". When the "Approved" radio button is selected, a CET/CEST timestamp is generated and pretty-printed correctly using the 'calculated value' section in an adjacent field. The XSLT used to do this is :

if ($Approval = 'Approved') then format-dateTime(current-dateTime(), '[D1o] [MN] [Y]  [H]:[m]') else ''

My problem is that this appears to be changed every time the form is viewed, probably because of the use of current-dateTime() in a calculated field. I guess there would be a way to generate a timestamp that can't change, but I haven't figured out how.

All suggestions welcome.

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for coding an Immutable Timestamp

Alessandro  Vernet
Administrator
Hi James,

Changing your expression into `if ($Approval = 'Approved' and . = '')
...` might do it. This would put a timestamp if there was not already a
timestamp there. And of course the timestamp would be rest of the
approval state changes, as the "else" part would run. Could this work
for you?

Alex

On Tue, Apr 28, 2015 at 1:42 PM, James Newcombe
<[hidden email]> wrote:

> I have a form that requires an approval step, and requires that the act of
> approving be timestamped.
>
> The approval takes the form of a set of radio buttons - "Approved", "Not
> Approved" and "More Information Required". When the "Approved" radio button
> is selected, a CET/CEST timestamp is generated and pretty-printed correctly
> using the 'calculated value' section in an adjacent field. The XSLT used to
> do this is :
>
> if ($Approval = 'Approved') then format-dateTime(current-dateTime(), '[D1o]
> [MN] [Y]  [H]:[m]') else ''
>
> My problem is that this appears to be changed every time the form is viewed,
> probably because of the use of current-dateTime() in a calculated field. I
> guess there would be a way to generate a timestamp that can't change, but I
> haven't figured out how.
>
> All suggestions welcome.
>
>
>
> --
> View this message in context: http://discuss.orbeon.com/Suggestions-for-coding-an-Immutable-Timestamp-tp4659857.html
> Sent from the Orbeon Forms community mailing list mailing list archive at Nabble.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> To post to this group, send email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for coding an Immutable Timestamp

James Newcombe
Alex,

Thanks, but that didn't work. I didn't get an error, but I also didn't get a timestamp. It's Orbeon 4.8.0 if that makes a difference.

Thanks,
James.

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for coding an Immutable Timestamp

Alessandro  Vernet
Administrator
Hi James,

Could some value be there in the node, so the test . = '' would fail?
Maybe you can check that by adding another control which returns
$timestamp = '', assuming the name of your timestamp control is
"timestamp".

Alex

On Tue, Apr 28, 2015 at 4:33 PM, James Newcombe
<[hidden email]> wrote:

> Alex,
>
> Thanks, but that didn't work. I didn't get an error, but I also didn't get a
> timestamp. It's Orbeon 4.8.0 if that makes a difference.
>
> Thanks,
> James.
>
>
>
> --
> View this message in context: http://discuss.orbeon.com/Suggestions-for-coding-an-Immutable-Timestamp-tp4659857p4659859.html
> Sent from the Orbeon Forms community mailing list mailing list archive at Nabble.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> To post to this group, send email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for coding an Immutable Timestamp

James Newcombe
Alex,

There is no value in the node, but our testers assure me that after a number of tests, they do not see the timestamp changing after the initial setting. That makes this a moot point. It feels like that's the wrong answer - if it's a calculated field, it's not clear to me why it would only be calculated the first time, but I'm told that's what's happening; and their testing was a lot more exhaustive than mine.

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for coding an Immutable Timestamp

Alessandro  Vernet
Administrator
Hi James,

So the testers are saying that there are cases where the "timestamp" fields stays empty, and isn't initialized by the current time when the approval changes to 'Approved'?

Assuming this is the case, I'm running short of ideas. To make progress I feel you would need to be able to reproduce the issue first, and then create an example where we can do the same.

Alex

On Thu, May 7, 2015 at 1:03 PM, James Newcombe <[hidden email]> wrote:
Alex,

There is no value in the node, but our testers assure me that after a number
of tests, they do not see the timestamp changing after the initial setting.
That makes this a moot point. It feels like that's the wrong answer - if
it's a calculated field, it's not clear to me why it would only be
calculated the first time, but I'm told that's what's happening; and their
testing was a lot more exhaustive than mine.



--
View this message in context: http://discuss.orbeon.com/Suggestions-for-coding-an-Immutable-Timestamp-tp4659857p4659895.html
Sent from the Orbeon Forms community mailing list mailing list archive at Nabble.com.

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet