Unha breve nota para comentar que LibrePlan vai estar nas próximas Xornadas Libres, organizadas por GPUL na Facultade de Informática da Coruña. Vou ter ocasión de voltar á facultade para presentar a ferramenta e, con sorte, volver a ver algunhas caras coñecidas.
O meu turno é o martes 24 ás 18:00, pero non perdades ocasión de asistir tamén a outras charlas. ¡Véxovos alí!
Today we are releasing the latest version of LibrePlan, numbered 1.2.3. The star of this release is the addition of the money cost monitoring system implemented by my team mate Manuel Rego, but there is a number of fixes added since the last release only one month ago, impacting small bugs, stability and performance.
The team is working hard to keep polishing the tool with the feedback of our users, while we work in new features for the next major release. We have some nice charts with new performance indicators, have improved the behaviour of the WBS table, and we keep working on other items in our roadmap. We had to delay the release date, but it’s worth waiting; meanwhile, download and try this new version!
We are building a more polished and stable planning tool day by day. Congratulations to all the members of LibrePlan community!
It’s been a long time since the last post about this tool. It was the announcement of beta 2, and a lot of things have been done in the >50 patches committed since then. Let’s review and update the TODO file of the last release:
Besides, there are bug fixes and usability improvements. All these changes can be seen in action in the public demo site.
As you can see, there’s little left to do to announce the final 2.0 release. But that won’t be the end of the road, but a milestone to take breath and keep coding.
I’ve been asked whether it was possible to install PhpReport in a Windows box or not, so I tried it and wrote the steps down in the INSTALL file. And now we have more concrete and precise installation instructions for Debian/Ubuntu, RedHat/Fedora or Windows systems, I felt like it was a good idea to package the application again, together with the bug fixes we pushed along the way. Take a look at the list of changes in the NEWS file.
Files can be downloaded here:
And they are also available in the project page.
Yesterday I silently added a link in PhpReport web page:
Lately I’ve been working on the simplification of the installation process; now it’s not necessary to download external libraries or set any special php.ini parameters, and I’ve added a database setup wizard taken from PhpReport 1.x series, which in turn was based on the one from WordPress project. So now to install PhpReport, you only have to extract the tarball, create the database and open the installation wizard from a browser to let it create the tables and initial data. More work will be needed anyway, to set up other installation methods (.deb packages, for example) and write specific instructions for different operating systems or distributions.
And this is the beginning of a release process. I will try to release new versions as I implement new features, giving priority to those listed in the TODO file, and provide update paths between them (unlikely at the moment, but it could happen in the future). And now I’ve mentioned the TODO, it lists the changes I consider essential to release a final, stable 2.0 version. Any volunteers? 
Ext JS is a good framework to build complex web UIs in JavaScript, because it provides many useful widgets. There’s always a dark side, anyway: in our case, when we started writing PhpReport 2.0, we had to rely on some undocumented features taken out from examples to get some things done.
Unfortunately, as new versions are released, some of these ‘features’ change their behaviour, or just disappear; maybe because they actually were side effects, or they were WIP. And moving to a newer version of the framework became an unexpected problem.
We started PhpReport 2.0 using Ext JS version 3.0, upgrading util 3.0.3. Then we found out that the jump to the next major version required more than downloading a new tgz, so we left it on hold, until some weeks ago, when I decided to get the latest Ext JS (3.3.1 right now) and put some effort debugging the problems caused by the migration. I share here with you the challenges I found.
XmlWriter and tpl attribute
This attribute is used to specify the conversion between the Store object with the data and the XML that has to be output, for example, to a REST service. To iterate over the fields of a record, we used this template: <tpl for="fields">. Now, that element isn’t called ‘fields’ anymore, and you should use <tpl for="."> to iterate over the fields of a record.
Null values on records
In Ext 3.0.3, Ext.data.Field objects didn’t have the useNull configuration option. It was introduced later, and its default value is false. This caused that some non compulsory fields stored a 0 when the user wanted them to be empty. The solution is simple: adding useNull: true to those fields when defining the corresponding Record.
Columns with empty ids on grids
When you used a empty string as the id of a column in 3.0.3, the grid showed a column with an empty label, and those records of the Store with an empty field name were rendered in that column. But that no longer works in 3.3.1, where every column has to have its id.
Changes in the behaviour of ref property
ref is a path specification, which allows us to place a named reference to a component in one of is owner containers. It seems there were some changes in the implementation of this attribute in Ext 3.1. Look at this example:
Ext.onReady(function(){
var g = new Ext.grid.GridPanel({
renderTo: document.body,
store: [1],
columns: [{
header: 'col'
}],
tbar: new Ext.Toolbar({
items:[{
text: 'Foo',
ref: '../deleteBtn'
}]
}),
});
new Ext.Button({
text: 'Click',
renderTo: document.body,
handler: function(){
console.log(g.deleteBtn);
}
});
});
It worked flawlessly in 3.0.3. When clicking on the button, the system writes g.deleteBtn in the JavaScript console. deleteBtn is not a direct child of g, but we achieved this direct access using ref.
After the migration, something ‘under the hood’ made this code broke, but taking a look at it, the only questionable thing is the definition of the toolbar, which can be simplified. After some experiments, I found out that the problem was fixed changing that definition:
tbar: [{
text: 'Foo',
ref: '../deleteBtn'
}]
Now ref works correctly again. Not sure about what happened, but it seems that the redundant definition of the toolbar now has this undesired side effect.
So…
It was an unexpected effort, but I’m happy with the results. I was waiting to get some annoying cross-browser bugs solved, for example, those huge calendars in WebKit-based browsers. I have the migrated code of PhpReport in a separate branch called migration-to-ext-3.3.1, and we are testing it heavily right now, before merging into master.
If you take a look to the repository history, you’ll notice that PhpReport is active, receiving patches to fix bugs and even some new features:
But there is something that has been in my TODO list for too much time: simplify the installation process and start releasing the application periodically in tarballs. That will be my New Year’s Resolution 
.
And by the way, Happy Holidays!
I haven’t posted about that, but I’m also involved in the development of NavalPlan, a production management application with features to schedule projects and follow their advance graphically, controlling the costs and deviations. I have to say its dynamic Gantt diagrams are quite impressive for a web application .
NavalPlan has a work report system to store the information about the hours devoted by the employees to every task scheduled, and also provides web services to import and export those data, so it felt natural to connect PhpReport, our time tracking tool, with NavalPlan, to share the dedication data.
I’ve started writing a plugin for PhpReport to be executed right after creating a task, with the purpose of sending that task to NavalPlan using its web services. Right now it’s functional, but lacks extensive error checking. I still have to write similar plugins for the update and delete operations.
Check out the code from the remote branch navalplan-plugins in PhpReport repository:
git clone http://git.igalia.com/phpreport.git git checkout origin/navalplan-plugins
This is how it looks, so far :
Tasks in PhpReport
The same tasks, imported into NavalPlan as a work report
In this brief post I’d like to announce the publication of the web site for the project PhpReport at the URL:
It will be updated progressively with new information: documentation, resources, etc. We also have the public bug tracker under https://trac.phpreport.igalia.com.
These sites are kindly hosted by Igalia .
We have just received the first picture of the event:
Bad Behavior has blocked 196 access attempts in the last 7 days.