kamibroke

kumpieling and instulaeshn:

the yuezhuull 'konfigur, maek, maek instorl' shood wurk (noet: yue shood be ruet wen instorling).

noet: the instulaeshn mae not wurk propurly. if wen yue run the proegram it wornz that the daetubaes inturfaes loeding faelz or the menyuebar iz mising moest ov its ietumz then yue wil need tu manyueuly instorl the liebrureez, kamibroke.rc fiel, survistiep fielz, survisz and iekonz.

the foloeing kumpield liebrury fielz:
- kamibroke/debug/src/kamibroke_library/libkamibroke.la
- kamibroke/debug/src/kamibroke_library/.libs/libkamibroke.so.0.0.0
- kamibroke/debug/src/dbinterface1/libdbinterface1.la
- kamibroke/debug/src/dbinterface1/.libs/libdbinterface1.so
- kamibroke/debug/src/general_journal/generaljournal.la
- kamibroke/debug/src/general_journal/.libs/libgenrealjournal.so
- kamibroke/debug/src/general_journal/generaljournal_config.la
- kamibroke/debug/src/general_journal/.libs/libgenrealjournal_config.so.0.0.0
shood be kopeed intue a liebrury direktury (such az /usr/lib).
the foloeing fielz:
- kamibroke/src/icons_desktop_misc/kamibrokeui.rc
- kamibroke/src/kamibroke/icons_desktop_misc/kamibroke_database.desktop
- kamibroke/src/kamibroke/icons_desktop_misc/kamibroke_journal.desktop
- kamibroke/src/kamibroke/icons_desktop_misc/kamibroke_report.desktop
- kamibroke/src/general_journal/icons_desktop_misc/general_journal.desktop
shood be kopeed tu an aproepreeut direktury wair KDE surchz.

fyuechur duvelupmunt

Kamibroke I (local single user, open-source, KDE-KPart based)

Milestone

Planned New Features
green=done : yellow=in progress : red=yet-to-do : blue=yet-to-plan

Version
0.4.0

• implement - general database search in dbinterface1

• implement - user options to select the locale and the designated general journal

• implement - scheduling transactions

Version
0.4.4

• design and implement - asset register/inventory view and management

• design and implement - asset register/inventory database storage and access

Version
0.5.0

• design - kamibroke´s native file format (research existing standards/formats)

• implement - saving and loading data

• uncomment intro dialog, implement new book functionality and opening balances

Version
0.5.3

• port and improve - other cash payments journal (based on previous journal from kamibroke 0.2.9)

• port and improve - simple australian wages journal (based on previous journal from kamibroke 0.2.9)

• port and improve - other cash receipts journal (based on previous journal from kamibroke 0.2.9)

Version
0.5.4

• design and implement - cooperative journal data sharing

Version
0.6.0

• create - generic purchases journal

• create - generic purchases-return journal

• create - generic sales journal

• create - generic sales-return journal

Version
0.6.2

• create - generic accounts payable journal

• create - generic accounts receivable journal

Version
0.7.0

• implement - reports galore : have a look at what other accounting programs offer and copy them

Version
0.7.4

• implement - period end/closing balances

• implement - import/export pluggin filter architecture

Version
0.8.0

This is the first fully working version of Kamibroke!

• implement - database selection and configuration

• implement - database interface for atleast one of the GPLed databases

Version
0.8.0 -> 1.0.0

• bug fixes

• improvements - user feed back for improvements

• features - code user requested features

Kamibroke II (secure networked POLA multi-user, open-proof, capability based)

Milestone

Planned New Features
green=done : yellow=in progress : red=yet-to-do : blue=yet-to-plan

Version
0.1.0

• wait - for a secure mirco-kernel 'open proof' capability based operating system (eg: Coyotos), device drivers, supporting standard libraries, windowing system and desktop environment to be developed : this will be years and years into the future.

• wait - for an object based language designed for use with networked capabilites and has constructs to assit automated software verification to be specified (eg: something like E with theorem proving constucts)

• wait - for a compiler and theorem prover for this language to be created

• design - a specification for Kamibroke (ie: a networked, multi-user, fine-grained security double-entry accounting program) that runs on this platform. This specification should include guarantees about the security and logical correctness of Kamibroke: eg. It should-: • Guarantee that the component journals/reports/etc. are confined and that the communications between the components internally on a machine and externally over a network are secure and occur only through authorised channels/interfaces.

WARNING: Rant follows- :)
Confinement is the reason why this cannot be based on KDE/KParts. I donot know any way to confine an installed part, I believe that it is actually impossible to do. Whenever you install a part on KDE, the part runs with full authority of the main application. It becomes 'part' of the main app. This means that an installed part cannot be stopped from accessing any system service that the main app can access. Ie: An installed part can access all the local files, internet addresses, memory addresses, hardware, etc. that the app can. Hence it is impossible to prevent the part from sharing its data with other installed parts. This means that the fine-grained POLA (Principle Of Least Authority) security scheme that I would like to have cannot be implemented.
Incidentally an application itself cannot be easily confined and still be useful on standard-linux/Windows/or any other main stream OS. Generally, programs on these systems run with the privileges of the user who owns them. This is almost always grossly excessive authority. Take for example, any text editor: when you command it to save a file, what you are really doing is asking 'Please program, out of all the files that you can modify,'- which would normally be most data files in the user's account- 'please modify the one named x...x.txt'. Whereas on a system that uses capabilities (such as Coyotos) when you ask the program to modify a file, what you are doing is giving it authority to modify that particular file and no others. So if, before you asked it, it had not be given any file modifying authorities, then the only file that it can change is the file named x...x.txt. One way to achieve confinement on traditional systems is to completely isolate the program from all others. This might work for a simple program such as a plain text editor, but for programs that are required to work cooperatively with other programs (such as programs that support Drag'n'Drop) this renders that program useless.
An interesting side-effect of this is that if using capabilites, when serializing the data it does not have to be encrypted. The only reason why data is currently encrypted in accounting applications is because other programs (such as the text editor above) can access it. (PS: I not saying that data exchange over the network doesn't need encryption. Packets sent over the network would still need to be encrypted like normal.); • Guarantee that the basic principles of double-entry accounting are observed by any installed component parts (eg: each new transaction created by a journal is balanced and occurs within the current accounting period; each new account is a descendant of one of the five major account types) otherwise the part is forbidden to do any processing on the database.; • Provide a security scheme that controls user authority. The scheme should allow authorities to be granted according to the POLA (Privilege of Least Authroity) principle. eg: Within a multi-department store, a junior sales assitant should only be able to make/edit sales/sales-return transactions within their department (with maximum amount restrictions) and not be able to do anything else. An accounts-payable clerk should be able to settle accounts due but not be able to create/edit/view any sales and not be able to create/edit new purchases. Whereas the company accountant should be able to view any transaction but only able to create end-of-financial-year transactions and special evaluation/adjustment transactions (eg:depreciation, goodwill). Lastly, a company director should be able to view any transaction but not be able to create/edit any.

A networked, object capability based architecture facilitates reasoning about these issues.

Version
0.1.0 -> 0.8.0

• implement - 'open proof' Kamibroke II according the specification.

Version
0.8.0 -> 1.0.0

• improvements - user feed back for improvements

• features - code user requested features

welkum tu the Kamibroke divelupur siet

introe:

downloedz:

Kamibroke proejekt-

udishnll jurnllz- (KPart kumpoenunt, opshnll downloed)

udishunll riports- (KPart kumpoenunt, opshnll downloed)

kumpieling and instulaeshn:

maeling list:

kurunt foekus ov duvelupmunt:

fyuechur duvelupmunt

skreenshots: