Until now I never knew that using FTP can be so easy.
Many of you would have started thinking about the FTP servers till now, but to be more clear here I am talking about SFTP (SSH File Transfer Protocol).

But as Shakespeare said "What's in name, the thing we call rose would smell as sweet with some other name".
And so is true for SFTP, as this provided the usability that I was looking for and that too with minimal configuration with some extra benefits which we will talk about in the last.

And not only that I was able to do this in two different ways.

• One is like my as colleague Juan Pablo says "It should be a JAIL for the user", so that he cannot move outside the directory.
• And the other one is like simple ftp which allows you to move around but not able to read or write unless you have permissions.

To know it better I think a use case will be really helpful.
So I will put down the requirement that pushed me to learn about it.
We needed to grant permissions to one directory to a user, with one directory I literally mean that, as we wanted to block him from peeping into other things.
That too with minimal access to system binaries and it should be secure etc etc.

And SFTP was the best suit for the requirement, you will get the answer of how in the next section where I have shown the configurations of both the cases and believe me it couldn't have been simpler.

Lets get into the jail first ;-)

• Edit /etc/ssh/sshd_config to include this.

Subsystem sftp internal-sftp
Match User sftpuser
ChrootDirectory /var/www/sftpdir (this makes the user stay under one directory)
ForceCommand internal-sftp

• Create the sftpuser and set it's shell acess to false, so that user is not able to do ssh.

useradd -m -s /bin/false sftpuser

• Give correct permissions to sftpdir.

chown root:root /var/www/sftpdir

• For increasing security I changed these also in /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

And I also added my pub key to /home/sftpuser/.ssh/authorized_keys file, but this is optional as this doesn't make any effect on the SFTP working.

For this jail method we are done.

Try connecting:
sftp sftpuser@localhost
Connecting to localhost...
Enter passphrase for key '/home/user/.ssh/id_dsa':
sftp>

Now lets get back and see the next way (I know most of us will not read this, as first one will work like a charm):

• Create a user with /usr/lib/openssh/sftp-server as shell and /var/www/sftpdir as home dir.

sudo useradd -s /usr/lib/openssh/sftp-server -d /var/www/sftpdir sftpuser

• Add this /usr/lib/openssh/sftp-server to /etc/shells file

echo "/usr/lib/openssh/sftp-server" >> /etc/shells

• For increasing security I changed /etc/ssh/sshd_config and also added my key to /var/www/sftpdir/.ssh/authorized_keys file.

PasswordAuthentication no
PubkeyAuthentication yes

• Set correct permissions of the sftpdir.
  

chmod go-w /var/www/sftpdir
chmod 700 /var/www/sftpdir/.ssh
chmod 600 /var/www/sftpdir/.ssh/authorized_keys

And done.

Try connecting:
sftp sftpuser@localhost
Connecting to localhost...
Enter passphrase for key '/home/user/.ssh/id_dsa':
sftp>


Now about the extra benefits:

• Easy to configure.
• Good in Security.
• Can work with PubkeyAuthentication.
• No extra installation (as uses SSH).
• Easy to use SFTP client.

at least these things are enough to pull me towards it.

That's it for taday. Happy SFTPing.

The portfolio of modules in the Openbravo ecosystem is growing rapidly and new modules become available every week.

In the past months I had the opportunity to help many developers publish their modules and I have observed a common behavior: the first module represents a psychological barrier and the first publication represents a sort of voyage of discovery after which people feel more confident and empowered; from the second time on, publishing a module becomes almost a joyful experience.

My advice to every Openbravo developer is to avoid hesitation. If you ever had the desire to publish a module, do not procrastinate: take a piece of simple functionality that you have developed for yourself or for one of your customers and publish your first module today.

There are many advantages in publishing your first module but I would like to mention what I consider the top three reasons:

1. Get over the learning curve. Publishing a module is easy but there are many small common mistakes that people make. Our experience shows that going through the process once allows you to discover most of the pitfalls; you can become an expert by simply publishing your first module.
2. Promote your work and become a star. If you are an IT professional providing services around Openbravo, publishing a module is a great way to promote your work in the Openbravo community and to become known among end users and other service providers.
3. Learn how to generate additional revenues. Many developers tell us that they are not ready to share their work with the open source community because they need to recover their R&D investment. Publishing your work as a commercial module and listing it on the Openbravo Exchange is a great way to accelerate that return of investment; you can now leverage the dissemination power of Openbravo and distribute your work as a commercial solution on a global scale.
   If you are not sure that you want to start by publishing a commercial module, start with an open source one and gain a much better understanding of the Openbravo ecosystem; that way, you will learn if commercial modules are for you.
   

You do not know where to start? Start from something simple and easy. Here are some ideas.

Reports are great examples of functionality that can be easily packaged and reused: if in your implementation you built a custom report to manage a specific process in your business, chances are that other companies might have a similar need. Take that report, package it and publish it as a module. An example of such a report is the Sales by Month Report.

The same thing applies to printed document (sales order, invoices, etc.) which are commonly adapted to the company branding and graphical style; if you developed your printed documents starting from the default document templates introduced in 2.50 MP20, any company specific information (name, address, logo, etc.) should be a parameter to the report and the document itself should be a generic and reusable template. Making your printed document template can help in building a portfolio of templates from which other users can pick and choose for their implementation. An example of such template are the US style business forms included in the US localization.

Alerts are another idea. If you have configured alerts to help you detect and correct exceptions in your business processes (for example: purchase orders overdue for receipts, product out of stock, etc.), other organizations might be interested in that same capability. Duplicate Period Alert is an example of such a module.

These are only some ideas to get you started but many other opportunities exist, including additional windows, processes and connector to web services. Of course you do not need to start with something this simple and in many cases the first modules people publish are quite sophisticated. The important thing is to get going.

Publish your first module today and be part of the fastest growing ERP ecosystem on the planet. Most importantly, have fun with Openbravo!

To help Openbravo partners and users we have extended our Sizing Tool Guidelines to include some more facts and findings.

"As more the better" --Harpreet Singh ;-)
Same has been proved by the new Amazon Cluster Compute Instance (cc1.4xlarge).

Amazon recently anounced the availability of it's biggest Instance, ideal for cluster infrastructure, as it promises high connectivity between cluster instances (as high as 10 Gigabit Ethernet).
But we tested this instance for the standalone test with Oracle DB and Openbravo on same instance.
The results were realy exciting as it was able to handle around 270 concurrent users.

Now truely speaking "Thats what I call results."
And the same results have been added to our Sizing Tool Results.

"There is no such thing as a free lunch." --Milton Friedman
This instance also has some drawbacks:
- It costs a lot (almost $1.60 per hour)
- Till now it is only available in US (N Virginia) region.
- And is only available with CentOS.

Now here comes another one.
As cost is the biggest concern when we think of any new infrastructure. For example: Running an instance (which can support 10 concurrent users) for 3 (THREE!!!) years on Amazon EC2 would cost only $1217.60, I think these figures can help one think about on-site and in-cloud (EC2) deployments.
So we extended our Sizing Guidelines to help you choose your Amazon Instance.

In the last section of the Guidelines we have added:
- Steps you can follow to calculate your yearly cost with Amazon cost calculator.
- As Amazon calculator is a bit complex so we created simple calculator to help you out.
- And pre calculated cost for most common scenarios.

A new major release is coming! On March 31st, 2011 the Openbravo ERP 3.0 is planned to see light.
It will come with several changes both Functional and Technological. The new release will have tons of cool features and a huge GUI redesign is planned… and this is good news, isn’t it? Well…

My first thought when I saw the mockups for new layout was “Yikes! This will be hard to implement in Selenium“.

From a strict Quality Assurance point of view, new stuff means more potential problems. Even if considering only our Smoke Test forgetting the rest of the testing cycles we do, it is clear that most of the test cases will require hard work in order to update them. And from the Automation side, there are even more issues.

But a moment later, my mind changed to “Wait a minute! We can do this. It is a challenge and challenges are the actual motivation for the team“. These mixed feelings are caused by the difficulties we expect to have along the new Automated Test development. Test cases do not playing the proper test steps and things like that.
However, those are actually the things that help us (to both QA Team as a unit and Openbravo as a company) to improve previous processes.

So the objective is to develop a fully functional Smoke Test and automate it to run against Openbravo ERP 3.0. In order to achieve the goal, we have identified several tasks.

• Design of new Smoke Test
  • Test cases review
  • New flows review
  • New suites organization
  • New test cases development
  • Test cases review (part 2)
  • Test case validation (with other teams)
• Design of new Automated Test
  • Classes (foundation) review
  • Diagram design (high level)
  • Component design (low level)
  • Prototyping
  • Deliverables testing

As we said in previous posts our expertise in Selenium is increasing rapidly. We are currently able to perform several types of tests and make reliable and fast test suites.

There are two main development lines that run in parallel, the Functional branch is intended to develop the test cases in Testlink according to the new flows that will be delivered in 3.0. Partially depending on this Functional, there is the Automated branch that will focus on Selenium issues.
One of the most evident features in 3.0 is the GUI redesign, and that means a direct hit in our foundation classes for automated tests. Furthermore, the use of a framework as Smartclient is a major drawback since from a plain HTML perspective the application is completely different from the 2.50 series.

As a conclusion, this post’s title should be changed to “Openbravo 3.0: What a great moment to develop more Selenium stuff!“

• Impersonal: the software does not seem to care about you and does not want to adapt to you
• Arrogant: the system treats you as if it´s your fault when things go wrong
• Technology driven, not human: yes, the software runs on an application server, pulls records from a database using SQL and is written in Java but guess what, I do not care!
• Fear of failure: the application does not give me confidence. I´m afraid of doing the wrong thing, losing data or looking like a fool to my colleagues
• Does not speak the user´s language: why do I have to talk the system´s language? Who´s in charge here? Hal? Hal?
• Hard to learn: unless my boss lets me do a one week course, it will be very hard to get to know the system
• Gives information you don´t need: reminds me of the Windows XP message: "You have unused icons on your desktop"
• Does not answer your questions: I´m sure the answer sits somewhere in the system, I just don´t know how to get it out
• Inefficient: do I really have to do all this to complete my task?
• Visually not pleasing: only moms like to look at ugly babies

Standard OFX

The module Standard OFX mainly used to import the bank statements from the OFX file. OFX format is widely used in banks for sending their client statement. Using the ofx file, Customer can import the bank statements and also customer can verify the bank statements with openbravo transactions statements.

Open Financial Exchange

Open Financial Exchange (OFX) is a data-stream format for exchanging financial information.Open Financial Exchange is a unified specification for the electronic exchange of financial data between financial institutions, businesses and consumers via the Internet.Open Financial Exchange is an Internet-oriented client-server system that features a direct connection between the client and a financial institution’s server, employing a request/response model using XML. Navigate  to this link for more detail Open Financial Exchange

Import Bank Statements

A customer can create purchase or sales invoice. He would maintain his transaction in the application. Bank will send the bank statements to the customer based on his transaction. Customer can match the bank statements with the application transaction statements.Using the ofx file, Customer can import the bank statements.

Configuration

The standard ofx module is  available as a commercial module in the Openbravo Forge for users on Openbravo ERP 2.50 and up. In order to make the most of this module, some configuration must be done. Once the configuration is done, Customer can use the feature of standard ofx. Further information is available in the Configuration Manual.

Technical Aspects

We have developed the functionality of this module in the following way: first of all, customer need to provide the ofx file.The ofx file contains transactions. We get the necessary parameters from the ofx file to import the bank statement. Created bank statements are available in the Import Bank Statement and Bank Statement Lines tab. After importing the bank statements customer can match the bank statements with existing openbravo statements using the matching algorithm.

Feel free to check out the Technical Documentation and Functional Documentation for more details!

License

The standard ofx module is a commercial module. User need to get the access to use the standard ofx module.User can obtain the obtain a copy of the License at Openbravo License.

Some weeks ago, on a return flight from London to Spain and while tinkering with the configuration of my Gmail account to setup Priority Inbox, this concept struck me: there is a very significant and important difference in user interfaces for configuration and user interfaces for transaction.

This might seem obvious to you; probably it should have been obvious to me as well many years ago, but - what can I say? - I am not a user experience expert and, when I finally understood it, it was a kind of a revelation.

A very common and always animated debate among business application designers is about information density. In one camp, you have people who prefer information packed screens that allow power users to access all of the information they need without ever having to scroll around or navigate away from their workspace. In the other camp, you have those who favor minimalistic and light user interfaces, free flowing and easy on the eyes, not to scare away the novice.

I have to admit: I assisted to this debate with fascination but I have always been sitting on the fence. I have strong visual preference for light screens with sparse fields; I find them more elegant and easier to digest. On the other hand, I can also see that if your job is to process hundreds of sales orders per day, you really want to be able to do that job as efficiently as possible and having a packed screen with every field and command you need in sight is certainly more effective.

Casual usage with the need to digest information from one side; repetitive usage of well known functions on the other. There is the difference, and in no other place is this difference more relevant than in configuration screen versus transactional screens.

Take as an example your email inbox. Most of us receive hundreds of emails per day and we expect our email application to let us process them as fast as possible. Taking Gmail as an example, your inbox is dense with information on emails, labels, actions, etc. that allow you to read, act upon and classify your messages very efficiently.

Now, look at your email settings page. The options are sparsely laid out and grouped; there is one field per row and to leave plenty of space for verbose field names with inline descriptions of their meaning; there is even space for an instructional video on top of the screen.

The usage of space is not optimized and you need to scroll up and down to see all the options but that does not matter because you are not going to come to this screen very often and, when you do, understanding the meaning of every option is much more important than making rapid changes.

Now, let's move this to the world of ERPs and let's take Openbravo as an example. With a few exceptions for manually developed windows, all windows are consistently generated based on their Application Dictionary definition to be as compact as possible. When Openbravo thought of this design, we had in mind transactional windows and this solution is certainly appropriate for that purpose.

However, in the case of setup and configuration windows, this approach forces developers to choose field names that are short but not very descriptive in order to fit in the compact layout. Take as an example the Tax Rate window where we have a check box named Cascade; any guess of what that might mean and what the implications on your tax calculations are if you check it?

What about the Base Amount drop down where you can choose among four different values? Do you immediately understand what that means?

Admittedly, setting up a tax engine is more complex than configuring your email client but the source of the complexity should be in the domain knowledge required to perform the task, not from the window layout. Also, why compromise?

Wouldn't it be better if configuration screens were to follow a different pattern not focused on space optimization but on clarity of the semantic? Fields could be laid out in a much sparser manner and have long titles with in line description informing users of the implications of the choice they are asked to make; we could add links to additional documentation or, following Google's example, even include some instructional video.

What do you think? Is this something worth pursuing? Should Openbravo consider supporting this type of configuration screens?

Give us your opinion by either posting a comment to this blog or posting your feedback in the UX Lab forum.

We are pleased to announce the availability of the new Credit Management - Dunning module.

This module supports the creation of Dunning letters; reminder letters that are sent to customers that have sales invoices overdue for settlement.

The Credit Management - Dunning module allows you to create a sequence of dunning letters. Each sequence can be customer specific, so that you send reminder letters that are appropriate for that particular customer, taking into consideration any grace period that you may wish to allow certain customers.

Additionally, the module allows you to automatically charge

• Dunning Fees,
  
• Fines for Late Payment and
  
• Interest on Arrears,

on those overdue invoices based on a number of flexible parameters. The fees and interest that you charge can be specific to certain types of customer, resulting an an extremely flexible solution.

The module keeps a full Dunning history, allowing you to quickly and easily establish what reminders have been sent to a particular customer for a particular invoice. It is also possible for a Credit Manager to quickly and easily mark an invoice as deferred if a deferral agreement has been reached with a customer

The Credit Management - Dunning module is fully compatible with Advanced Payables and Receivables. More information on the Credit Management - Dunning module can be found here.

The Credit Management - Dunning module was made Generally Available on 18 October 2010 and is a commercial module available exclusively to Professional Edition subscribers.

Short flight conditions:

• Altitude – 2 973 downloads (Already more then twice higher then for the 2 months of RC1 – 1 248).
• Temperature overboard – +10 C. Autumn also happens in Spain .

From the crew radio exchange:

• Friday, September 17, 2010

[11:03:58 AM] Asier Zabaleta: just wanted to say a few things about APRM module

[11:04:05 AM] Asier Zabaleta: that I have been training this week in Madrid

[11:58:08 AM] Dmitry Mezentsev: Hello Asier, Once you are available it would be great to hear your feedback.

[1:37:09 PM] Asier Zabaleta: on monday

[1:37:24 PM] Asier Zabaleta: just in advance, it has been a kick ass success

[1:37:38 PM] Asier Zabaleta: very easy to teach

[1:37:44 PM] Asier Zabaleta: and every user need is covered

• Saturday – Sunday, October 9-10, 2010

[04:29:00 PM] pjuvara: Georgi, I’m happy to see people playing with 3.0.

[09:52:00 PM] Georgi: I love the product

Want to join the crew? Press this button !!!

Up to now the 2.50 and 3.0 versions of Openbravo have shared the same Core. “Core” is what we call the most essential module of Openbravo, the one that includes standard functionality like Financial or Sales Management.

If 2.50 and 3.0 have shared the same Core, what’s the difference between them? While a default 2.50 installation includes just Core, the 3.0 version includes a distribution of several modules: right now “Core” plus 16 more.

In terms of source code management we decided to keep one code line as much time as possible, simply because it reduces our developer’s backporting work. Backporting basically means that a bug fixed in 3.0 should also be fixed in 2.50 (if it affects 2.50, of course).

The news is that we have now reached the point where the 2.50 and 3.0 Core cannot share the same code any more. So we are planning to branch the 2.50 and 3.0 code-lines around the 15th of November.

And that’s not all about it. According to our plans we’ll be releasing version 3.0RC3 precisely the 15th of November. The extra news is that we’ll be having two 2.50 MPs on November, 2.50MP24 and 2.50MP25. Why? Simple, as the “Core” is still shared between 2.50 and 3.0, version 3.0RC3 will be needing some code not ready yet in 2.50MP23. And this is why we need 2.50MP24.

In terms of timing, we’ll freeze 2.50MP24 the 1st of November and release it the 15th of that month. So are we releasing both 2.50MP24 and 3.0RC3 the 15th of November? That’s right, and starting from that point the 2.50 and 3.0 Core code-lines will follow their own paths.

Lastly a couple of notes about how this affects to the 2.50 to 3.0 upgrade process:

1. While we are introducing a separate branch to simplify our code management, 3.0 is just another version of core and updating from 2.50 MPx to 3.0 is not any different than updating from 2.50 MPx to 2.50 MPy. In both cases, it is a full code replacement of core and, as long as the system has been configured using the principles of modularity and does not contain any core customization, system configurations and extensions are going to be preserved during the upgrade.
2. We will be cleaning the 3.0 core more aggressively than we are doing with the 2.50 core. Because of that, we can expect a higher volume of API changes in the 3.0 code line for the next few months and up to general availability date. However, we will continue to be conservative in 3.0 as well and accept only low risk API changes in an effort to minimize the chances to break module dependencies.  3.0 API changes will be listed in the Release Notes and users intending to upgrade from 2.50 are encouraged to monitor those notifications.

Tagged: API, Mercurial, Release process, Releases, SCM