Hi,

I am currently evaluating Ontime Windows and Web for use as a incident reporting and feature request system.  I have a query around how OnTime keeps a chronological order of communication between support and customers.  I ask this because in my testing I am able to completely remove text entered by another user and the Time stamp functionality in the Web portal inserts at the end of text and the windows client at the top.

I would like to know if there is anyway of stopping users from wiping out other peoples text, this goes for, Description, Notes Resloution etc.

 I would also like to know if the  label "Project" and "Name" in incident templates can be renamed.

Thanks

Hi,

to change labels go to tools > system optoions > click field labels > click on incidents > you can rename the labels here.

there is no way to allow users to have access to description, notes...etc. fields and not let them remove text. If they have acces to the field then they can edit anything. We do have audit trails of actions performed in case this become an issue for you guys.

Thanks,

Arash

Hi,

 Ok, we can live with the editability of the fields.  But it would be good if the time stamp functionality were enhanced as follows:

In my case I have set the stamp to insert at the top, which is what happens in the windows client, however the portal inserts at the bottom, but don't know why. I can't find any settings specific for the portal, so am suggesting it might be a bug.

 Also when the stamp is inserted it would be much more helpful (especially for the less experienced computer users) if the text cursor was automatically repositioned straight after the time stamp. Currently the cursor is not moved. Doing this would increase the relability of getting a chronological history of a discussion rather than relying on audit trails.

 Please let me know if the way I want to use OnTime does not follow best practice.

 Thanks

Hi,

Portal should be inserting the same way as windows so its a defect. I will add it to our system for future release. thx for the feedback on this.

What client are you using with the stamp cursor position? windows or web? if web what browser?

Thanks,

Arash

Hi

I am using the windows and web clients.  Both are exhibiting the behaviour of leaving the cursor at current position when a stamp is inserted. Also, when the editable tab is first opened and the first thing you do is insert a stamp, the cursor remains at the end of any text that may be present. So when you start typing it is at the end of text not after the stamp.  Obviously this only occurs when you insert the stamp at the top and would not be observed if you inserted the stamp at the end.

P.S a side question, are you using OnTime for these forums?  If, so this is exactly the way we want it setup.

Browser is IE7

 cheers

ashis

To a certain extent you can control who can edit what.You do this by normally disabling the fields in which editing must be restricted, and by providing special "editing" workflow steps, each of which is accessible by a different security role; a field template must be associated with each such "editing" workflow step which allows that security role to edit the field to which they have access.

For example, say you have two security roles "Developers" and "Testers". You could define a large text field "Developer Comments" and a large text field "Tester Comments". The "Developer Comments" field is enabled for editing on a field template called "Developer Comment Editing Field Template"; the "Tester Comments" field is enabled for editing on a field template called "Tester Comment Editing Field Template"; both fields are read-only on the default field template. The template "Developer Comment Editing Field Template" is associated with a workflow step called "Being Edited By Developer"; this workflow step can only be selected by a member of the Developer security role.The template "Tester Comment Editing Field Template" is associated with a workflow step called "Being Edited By Tester"; this workflow step can only be selected by a member of the Tester security role.

Users must remember to revert the workflow back to a "non-editing" step before saving, in order to protect their edits from the enemy.

We use this technique to a limited extent for protecting smaller fields. In our experience, users don't intentionally (or accidentally) overwrite other users' edits in large text fields.

If you're wondering why we don't just use field-access security for this purpose, it's because in fact we have lots of security roles for different project areas, and we don't want to have to define special field-access restrictions for every security role just to prevent them from accessing the fields with restricted editing rules, so we do this via field templates instead.

In our situation your solution is not workable.  We are wanting to use OnTime for providing support for our customers.  The conversations between support and customers need to be captured in chrological order and ideally should not be modifiable once saved.  These conversations could go back and forth several times, so a fixed field approach would not suit.  As OnTime does not have the functionality to "lock off" previously entered descriptions, notes etc the risk persists that text may be changed. Perhaps this would be a good enhancement.

Thanks

Ashis