Followup Documents

A great new feature is the completely reworked handling of so called follow-up documents. Kraft has this feature to help dealing with docs that follow on a certain kind of predecessor doc in the business flow, such as an invoice follows on an offer once the work has been finished.

To achieve that and to have all the items of the offer again referenced in the invoice, the Kraft user justs clicks on the menu item “Create Followup Document” on the selected offer, and the new doc is created with all the items of the offer prepared. It is ready to be adjusted to the final invoice details.

Now with version 0.90 this has even improved. Often, the flow is a bit different because a partial invoice is sent while the job is still in progress, for example to cover cost for material. A partial invoice usually has only one item, which is the progress payment the customer should pay.

Kraft users can handle that now very easy: The new UI does not only allow to choose from which predecessor document the final invoice should copy the items (which usually is the offer in the beginning) but it also realises that a partial invoice was sent before, so this amount of payment has to be substracted from the final invoice. Kraft adds an item to the final doc automatically here.

This helps to create high quality documents for your customers even faster, which is exactly the mission of Kraft.

Other Improvements

In addition to that, as usual a lot of other visible and invisible changes have gone into this release. For example, the UI has been simplified again by a clean up of the menu for example. The About Kraft dialog was removed and integrated into the Kraft information page.

Under the hood, we finally added unit tests, which is just a start so far, and ntroduced a new, XML based system to manage the available document types which makes igrations way easier. Last but not least the python based pdf conversion script was ported to python 3 to be ready for the end of python 2.

Community

Last but not least, Kraft got new contributions from the community: A new document type was initiated by a community member, which is a offer like document without showing the price information. Also, the complete app was translated to Dutch by a volunteer, and the translation is now shipped with Kraft by default. Also, other smaller bugfixes went in.

Thank you all for your help to improve Kraft.

But there is even more opportunity: Additionally we are looking for an ownCloud Desktop Client developer. That would be somebody fluid in C++ and Qt who likes to pick up responsibility for our desktop client together with the other guys on the team. Shifted responsibilities have created this space, and it is your chance to jump into the desktop sync topic which makes ownCloud really unique.

The role includes working with the team to plan and roll out releases, coordinate with the server- and mobile client colleagues, nail out future developments, engage with community hackers and help with difficult support cases. And last but not least there is hacking fun on remarkable nice Qt based C++ code of our desktop client, together with high profile C++ hackers to learn from.

It is an ideal opportunity for a carer type of personality, to whom it is not enough to sit in the basement and only hack, but also to talk to people, organize, and become visible. Having a Qt- and/or KDE background is a great benefit. You would work from where you feel comfortable with as ownCloud is a distributed company.

The ownCloud Client is a very successful part of the ownCloud platform, it has millions of installations out there, and is released under GPL.

If you want to do something that matters, here you are! Send your CV today and do not forget to mention your github account :-)

Many users of the ownCloud Client were asking for sync progress information, in fact there was none at all until today which is a bit boring. The reason why we hadn’t it was simply that csync, which is the file synchronizer engine we use, did not have an API to hand over progress information of an actual up- or download to higher levels of the application.

We implemented two callbacks in csync: One that informs about start, end and progress of an up- or download of an individual file. Another one processes the overall progress of the currently running sync run, indicating for example that eight files have to be processed, current is file number four, and x of the overall sum y bytes have been processed already.

That information is passed into a singleton class called ProgressDispatcher in the client code, where other classes can connect to a signal providing that information. That comes handy as we need the information at different places in the client GUI. [caption id=“attachment_299” align=“alignright” width=“399”] Sync Progress Display[/caption] The screenshot shows the first and probably most detailed implementation of the progress display in the sync accounts details which are part of a new settings- and status dialog.

The visual appearance was worked out by our interaction designer Jan. We always have to argue a bit because obviously I am the greatest interaction designer around ;-) but well, finally we do like Jan says and the result is great IMO. It’s great that we have him for ownCloud as that guarantees that our project is not drifting too much onto the geeky techy side which (I heard) is scaring off some users…

Hope you like it! You can get a preview in the current nightly builds (win, mac, Linux) of the client! Please report bugs as you find them, thanks.