Disable editing of transactions, is it possible?

Daniel Karlsson dannionio at gmail.com
Tue Jan 18 15:00:59 EST 2011


On Tue, Jan 18, 2011 at 8:55 PM, Jeff Kletsky <gnucash at allycomm.com> 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?
>
> My first stab would be:
> * Date of transaction
> * For each split
>  - amount of split
>  - target account
> * Number of splits
>
> This would allow notes and descriptions to be updated, but not the core
> financial data
>
>
>
> When would the UI lock need to be applied?
>
> On first entry seems like the most conservative, but potentially very, very
> annoying ("Oh &^%$&, I didn't mean to click there and now that entry is
> locked.") When one or more constituent splits were marked as "cleared" or
> "reconciled" seems like a natural point for me, but may not meet the
> requirements of the tax codes or GAAP of the jurisdictions.
>
>
>
Transactions for the same day might perhaps be editable? Best would be to
let the user decide.


>
> An interpretation on the applicable Swedish and German codes would be most
> helpful for answering both of these.


I'll look into it, might have an answer by the weekend.

>
>
>
>
>
>
> On 01/18/2011 10:07 AM, Daniel Karlsson wrote:
>
>> On Tue, Jan 18, 2011 at 1:38 PM, Mike or Penny Novack<
>> stepbystepfarm at mtdata.com>  wrote:
>>
>>    Adding an option to make transactions
>>>
>>>> read-only/disable editing may seem unnecessary, in fact the only purpose
>>>>> of this would be to make the software available to Swedish accountants
>>>>> in
>>>>> smaller firms and organisations. If one would want to cook the books
>>>>> this
>>>>> feature will do nothing what so ever to stop him, but this feature
>>>>> would
>>>>> make the software comply to Swedish law.
>>>>>
>>>>>  Misunderstanding what I was saying?
>>>>
>>> Perhaps the Swedish lawmakers need to call in Swedish systems analysts to
>>> explain this to them.  I was saying that no software CAN be compliant
>>> with
>>> "prevents the data from being altered". What such software COULD do is
>>> prevent that alteration unless other (unrelated) laws and civil
>>> restrictions
>>> were violated in the process. Thus the terms of your license with some
>>> commercial software product likely says that you are not allowed to
>>> examine
>>> the code and/or internal data formats and may not use the code for other
>>> purposes of your own.
>>>
>>> But that's not "in the code" but in the licenses.
>>>
>>> Let me try to make this clear. Let's suppose that the developers did
>>> exactly what you suggest, created a "Swedish version" which had a line of
>>> code that disabled the edit transaction process. But this is OPEN SOURCE
>>> SOFTWARE. Are we to suppose that Swedish programmers/analysts* are too
>>> incompetent at their craft to be able to create a "slightly modified"
>>> version to be used when one wanted to edit the data? This isn't a task of
>>> writing an entirely different version of the program but changing just a
>>> couple lines of source code and recompiling.
>>>
>>> The only way I can interpret the law in this case is making OPEN SOFTWARE
>>> illegal for accounting purposes.
>>>
>>> Michael D Novack
>>>
>>> * or ones elsewhere anywhere in the world who for whatever reason wished
>>> to
>>> do this and offer their version to Swedes
>>>
>>>
>>>
>>>>  --
>>> There is no possibility of social justice on a dead planet except the
>>> equality of the grave.
>>>
>>>
>>>  To be honest I hadn't considered the roles licenses plays in this, and
>> neither am I an expert on law, far from it, but I believe that software
>> doesn't have to prevent the data from being altered, just making the
>> option
>> unavailable is enough. If someone change the code of the  "Swedish
>> version"
>> to allow editing and used it to edit transactions might be considered the
>> same as writing a tool to access some proprietary database to change
>> transactions, Of course the editing of GnuCash isn't illegal, but using
>> such
>> an edited version to change transactions would be.
>>
>> Several Swedish accounting programs store files in plaintext, or some
>> easily
>> accessed database. The data is in no way protected against tampering, yet
>> they are approved simply because the GUI does not allow it. Yes, this law
>> isn't attuned to the reality and Swedish lawmaker do need someone to
>> explain
>> that to them. But adding an option in GnuCash might be easier than to
>> change
>> the mind of the government :P
>>
>> One way to implement this would be to make the option to make transactions
>> read-only available when creating a new file. I'm not familiar with
>> CnuCashs
>> design so I don't know if that's a viable solution, but from a Swedish
>> users
>> perspective that would be perfect.
>>
>> If a patch was submitted, making the option to make transactions
>> read-only,
>> would it be accepted?
>>
>> Daniel
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>


More information about the gnucash-user mailing list