Is this a common practise? I way toying with this idea because really after a while records should be filled in and not prone to the old accidental edit. 

 

This would be determined by business rules.  Financial records (Invoices and their LineItems, including payments) should be POSTED at month-end and no longer accept edits.  An Invoice, if printed or given to a customer should then be prohibited from modification.  It is common also that others cannot change your work and vice versa but managers might be allowed to change everyone's work.

 

These business rules should be enforced using Security and privilege sets.

 

So yes, it is common practice.  :-)

Many Thanks!

My approach will be -but I am very conflicted about going ahead with it- to underlay merge fields, and hide it if a substraction of creation date and current date exceeds a certain % of days. The reason for my not feeling certain about going ahead with it is a basically Webdirect. I have put a lot of time and effort  to optimize it with themes(kudos btw to fmi, with a few much needed changes, themes kick ass, for v.1 at least for sure)it and am well aware that each added element taxes the system... 

 

The alternative of using priviledges is a great idea as an adjunt, or similar purpose strategy, but doesn't realy fill in the gap, imho and in my application. 

 

I'd love it if someone gives me some feedback on that. 

really after a while records should be filled in and not prone to the old accidental edit. 

 

Do you only want to prevent accidental editing - but allow intentional editing? If yes, then this is not really a matter of how much time has elapsed.

First of all I stand corrected in some of my assumptions, I 've been reading the documentation of fmi in terms of security privileges and it's more robust than I thought, to allow me to sorta do what I want to . For the time being I am inputting a boolean for data created - date now < 360 say for a year to lock the edit in all  fields on a per privilege set basis.

 

Hey Comment, thanks for your input! Yes that's what I want to do. I am quite aware this is just a workaround that's not, well, working it's way around the way it should. I could potentially add some script I guess to reverse this on a case basis so some editing can be done, but I think I am about to make a blunder and this is not possible. In any case my understanding in terms of how time factors in is that, after you fill in a form, and you have a timeframe to correct something, why have have it open to edits that might create errors? Thus time factors in greatly here, anything left open to changes over time is bound to have the wrong changes applied to it. But of course it's not only about time...

 

What is your approach to that? For example, to break down my issue. Say you have a few slider panels with quite a few fields and you have your user swiping around on a ipad and browsing old company records, say an exec, maybe he plays about with it a bit too, to see how some fields work out, you know anyone mucking about in layouts full of fields with pop ups and sliders... I fear it's pretty easy to screw things up as opposed to say a spreadsheet situation, not that I am in anyway in favour of spreadsheets. So, that's in essence what I am trying to figure out. And as you rightly said I cannot get to my objective, to prevent such mucks ups, only with my approach with time. It's just a small safeguard I guess. 

I try to put a sharp line between restrictions that enforce security and/or business rules (e.g. 'you cannot edit an invoice once it has been printed') and limitations that are part of the user interface (e.g. 'you cannot edit this record unless you click the "Edit" button - which will put you in Edit mode').

 

In the second case, it would be bad user interface (IMHO) if the mechanism to edit the record were to change according to the age of the record.