Disable editing of transactions, is it possible?

[Jeff Kletsky]

No confusion.

If the applicable codes are met by being able to demonstrate that the 
software in use makes "reasonable efforts" to prevent changing the data 
through the UI, then we're done.

I deal with this in enterprise software that manages legally binding 
contracts for one of the most highly regulated industries in the US, as 
well as serving customers throughout the world. Yes, you can go ahead 
and access the database directly. Party on -- you can't stop that. 
However, we can demonstrate that the product, used as intended, takes 
reasonable efforts to preserve the state of the contractual information.

Digital images and the availability of Photoshop didn't make photographs 
inadmissible as evidence. Shoot, even before then, a good photographer 
could significantly modify the print or even a negative in the darkroom.

That this is Open Source software doesn't change it at all, as far as I 
am concerned. If you "cook your books" you are probably violating the 
code or GAAP, no matter how you do it; modified executables, accessing 
the data directly, or even completely re-entering all the data.

I'm willing to explore the requirements and potential implementation 
approach for a feature that may have benefit to a variety of users with 
a variety of use cases.



On 01/18/2011 12:30 PM, Mike or Penny Novack wrote:
> Jeff Kletsky wrote:
>
>> Rather than beating ourselves against the potential "stupidity" of 
>> government regulations, perhaps considering it as a "useful feature" 
>> and coming up with some requirements would be productive. One of the 
>> things I *hated* about Quick-whatever was that you could totally 
>> screw things up unintentionally. I'd welcome a feature that "locked 
>> down" transactions that I had, for example, marked as "cleared" or 
>> "reconciled" one or more constituent splits.
>>
>> What data would need to be locked from UI editing?
>>
> Confusion?
>
> We are talking about different things? UNINTENTIONAL vs INTENTIONAL 
> editing? The latter being illegal in the jurisdiction.
>
> We are interpreting CAN'T in different ways? It isn't going to help in 
> the slightest to make GnuCash "Swedish version" (that doesn't allow 
> editing that would be illegal in Sweden) if a Swedish user of GnuCash 
> who wanted to cook the books could simply edit the data whenever he or 
> she wanted to by using a non-Swedish approved version of the program. 
> Programs aren't the data. What I was trying to say is that IF the 
> requirement (of some jurisdiction) is based upon what the software 
> application can or cannot do with the data then no "open source" 
> software can be used (since anybody who wants to can make their own 
> modifications to what the software can do).
>
> I am having a little trouble understanding the difference between
> a) If in some jurisdiction I am not allowed to edit the transaction 
> (need to enter a correcting transaction) refraining from using the 
> "edit transaction" button.
> b) If in some jurisdiction not allowing a version of the application 
> where editing is allowed refraining from editing my data using a 
> version of the application that will do editing.
>
> To take your example -- imagine that you had this version with the 
> lockdown feature. Would this prevent you from changing a locked down 
> transaction using a different version of the program that ignored 
> "lock down"?
>
> With proprietary software it is separately illegal to create a 
> different version (besides being much harder)
>
> Michael
>