New developer in Dokeos – Herodoto

Herodoto is joining the Dokeos development team as an independent (and distant) developer today. He will be in charge of integrating the wiki tool, under my coaching. The wiki was previously a separate plugin in Dokeos, so we hope it will be stabilised and integrated in time for 1.8.6 at the beginning of October.

Herodoto (aka Juan Carlos) has already contributed a few patches to Dokeos in the past and he has a series of good idea to improve Dokeos’ messaging system overall (combine and improve forum, announcement, dropbox and the messaging plugin all together).

Depending on his contributions in the future, we might encourage such new blood to join Dokeos in the next months, to help in the move to Dokeos 2.0, by having experienced developers coaching them.

Hug a developer

http://www.develop-one.net/blog/2008/08/27/HugADeveloper.aspx

So realistic…

Entrando al planeamiento de Dokeos 1.8.6

Hoy conversé con Eric Marguin, mi contraparte francesa, y nos quedamos programando más o menos una semana definida para la publicación de Dokeos 1.8.6. Esto sera en la semana 41 si todo sigue según lo planeado, lo que cae entre el 6 y el 10 de octubre del 2008.

Aunque no podremos hacer el rediseño completo de la herramienta de ejercicios como lo habíamos programado, hemos agregado bastante opciones a este y completado otros desarrollos de otras herramientas. Todavia es demasiado temprano para hablar de esto, pero regresaré en medio setiembre para aclararlo todo.

Entering schedule for Dokeos 1.8.6

Today I had a phone chat with Eric Marguin, my french counterpart, and we ended up scheduling more or less a fixed week for the release of Dokeos 1.8.6. This will be week 41 if all goes according to plan, which is between the 6th and the 10th of October 2008.

Although we won’t be able to do the complete quiz tool revamp we wanted, we have been adding quite a lot to that and completing our developments on other tools. It’s still too soon to talk about all that, but I’ll be back around mid-September to make it all clear.

Quick-change header for eTiny

eTiny (OpenERP’s web server) shows default header images and style that might not really suit your needs.

OpenERP with default style

Being GPL, you can modify that at will, but you have to know how.

Although it’s probably not the best way to do it, you can easily alter the existing images to show something a little different.

This is all done (on a Debian/Ubuntu server) by changing the files in /usr/lib/python2.4/site-packages/eTiny-1.[0.1.1]-py2.4.egg/tinyerp/static (the part between brackets may vary) to suit your tastes.

The important files are

• css/style.css
• images/developped_by.png
• images/mainmenu_button.png
• images/openerp_big.png
• images/openerp_small.png
• images/sidebar_button_bg.png

So just make a backup, open them, change them and put them back in to get a very light (but refreshing change).

Open ERP using blue style

OpenERP y el mercado peruano

Dokeos Latinoamérica esta estudiando ahora la posibilidad de adecuar OpenERP al mercado peruano (a lo menos en la parte del plan contable).

Esto brinda mayores posibilidades para empresas e instituciones peruanas de finalmente tener un sistema ERP de grande tamaño a menor costo que las soluciones Oracle y SAP.

Deberiamos entrar en fase operativa con este sistema en el fin de setiembre. Desde ahí empesaremos a proveer esta solución como uno de nuestros productos principales.

Caching in eTiny, OpenERP’s web server

I recently learnt that eTiny, OpenERP’s web server, is actually caching pages when in “production” mode (this mode can be changed in the configuration file which is /etc/etiny-server.cfg if you followed the documentation here).

This means that installing some modules may not have a direct visual effect if you have already seen a page before altering it with the module installation.

To avoid caching, you can either change the eTiny server mode in /etc/etiny-server.cfg (to “development” I guess), or simply restart the eTiny server. This will erase the cache.

Of course, none of these methods is actually acceptable once the server is in production, but at least there is a way… (I suppose a way to clean the cache via a script while the server is running would be good).

Language detection in PHP

This is a *very* short note, but I’m writing it down in case I would forget in the coming weeks. There is a language detection package available in the PEAR project, which might come handy in the future for Dokeos:

http://pear.php.net/package/Text_LanguageDetect

Dokeos Latinoamérica celebra primer cumpleaños

Ocurrió sin plantearlo… Dokeos Latinoamérica cumplió su primer aniversario hoy, 23 de Agosto.

Aunque el inicio de nuestras actividades fue lento, estamos hoy 4 personas trabajando activamente, con 2 personas adicional trabajando para varios proyectos adicionales ocasionalmente y tres empleados más planeados para el fin del año.

Espero que tendremos mucho más cumpleaños así!

Primer cumpleaño de Dokeos Latinoamérica

He tomado (y modificado) esta foto de keke en Flick’r para ilustrar un poco el post :-)

Changing Dokeos style, #2

A few weeks ago, I explained how to change the Dokeos footer to make it “float”. Today, in the context of an indirect contract with the Ministry of Education in Peru, I have to change the style a little bit more.

The idea is to [1] have a left bar showing large tools icons in the course homepage, and [2] have an alternative portal homepage for users, showing an introductory screen of the main general tools. This must all work on a 800×600 screen (which is a real challenge).

[1] Left toolbar showing course tools

This is not as tricky as it sounds (although it’s very close to it). There is a set of options in the administration panel that allow us to show a floating menu of short links to tools. It is recommended to use a style based on “Public Admin” to do that, as this is now the default for Dokeos, it is up-to-date and it works well with the feature we’re about to use.

Although we are basing this on the “Public Admin” style, it is important to note that it would be smart to actually start from “Dokeos Classic” instead, as this style is better suited for 800×600 display (Public Admin is, in fact, more suited for 1024×768 or larger). Nevertheless, in the context of this first challenge (left tools menu), it’s more easily explained with Public Admin.

Let’s first activate this menu:

Go to Portal administration -> Dokeos configuration settings -> Course, and look for the option “Display course navigation menu”. Change it to “Icons and text”.

Now go inside a course. Hoooo, a nice menu has appeared on the right.

OK, so we want this menu on the left instead… Lucky us, there is already a bunch of CSS directives to move this menu from right to left inside the main/css/public_admin/default.css style. Look for “#toolnav” and the following commented code. Comment the first part, uncomment the second, save and reload. Now this *should* have moved the menu to the left (if not, take a look at the following code, this should do it).

#centerwrap {
width: 100%;
/*  float: right; */
/*width: 100%;*/
/*margin-right: -95%;*/
/* margin-left: -95%;*/
/* this needs to be less than 100% for Moz/Mac which thinks
it’s empty otherwise. The difference is made up by putting a
negative left margin on the left float:
Note IE/Mac doesn’t like this method ~ it wants the 100% so it can
be fed in using IE only CSS below becasue IE/Win also works with the 100% method.
*/
}
/* — course navigation menu as a definition list  — */
#swap_menu_link
{
float: left;
}
#toolnav{
float: left;
margin-right: 15px;
width: 154px;
}
#toolnavbox {
margin: 0 0 0 10px;
padding: 0;
/*float: left;*/
border: 1px solid #f0f0f0;
}
#toolnavbox dl {
width: 150px;
margin: 0 auto;
padding: 0;
background: transparent;
font-size: 12px;
text-align: center;
}
#toolnavbox dt {
margin: 0;
padding: 0;
font-weight: bold;
font-size: 12px;
text-align: center;
color: #000;
border-bottom: 1px solid #fff;
background: transparent;
}
#toolnavbox dd {
margin: 0;
padding: 0;
color: #009;
text-align: left;
border-bottom:1px solid #fff;
background: #E5EDF9;
min-height: 35px;
padding: 10px 0px 10px 10px;
}
#toolnav img {
float: left;
width: 25px;
height: 25px;
margin: 0 4px 0 0;
}
#toolnavlist a, #toolnavlist a:link {
background: #E5EDF9;
/*color: #dcdcdc;*/
color: #333333;
padding: 1px 1px 0px 2px;
margin: 0 5px 0px 0;
text-decoration: none;
display: block;
}
#toolnavlist a:hover {
background: #fff;
/*color: #dcdcdc;*/
color: #333333;
}
#toolnavlist a#here {
background: #fff;
/*color: #dcdcdc;*/
color: #333333;
}

See the #swap_menu_link over there? Well, there is a small missing feature in Dokeos 1.8.5, whereby the swap_menu_link item has a style hard-coded in a script. It is fixed in 1.8.6, but if you want to fix it in 1.8.5, just edit main/inc/tool_navigation_menu.inc.php and remove the “style” attribute from the declaration of the element with id=”swap_menu_link”.

That’s it for a left menu (you might get alignment problems in some cases, but I leave the little details for you to fix following your taste).

[2] Different portal homepage for logged-in users

This is also a littlebit less tricky than it sounds (although some improvements might be *very* tricky to add).

The idea is that we don’t want to get rid of user_portal.php, because it serves us well, but we would like to add a page to which the user will be directed when he logs in. This can be done through the very useful configuration variable “page_after_login”, which you can select in Portal administration -> Dokeos configuration settings -> Platform, but which only offers two possibilities by default: “Portal homepage” and “My courses”. We want to add one.

First let’s make a copy of user_portal.php and call it “my_homepage.php”. Let’s change some text in there to show that we are actually viewing the new page when we log in.

Second, let’s add this page as a choice in the portal administration panel. This can be done by adding a row to the settings_options table:

INSERT INTO settings_options (variable, value, display_text) VALUES (‘page_after_login’,’my_homepage.php’,’Custom homepage’);

Once this is inserted, and if we select this option in the administration panel, the page will appear when anyone logs in.

This is all very well, but the problem is that this page isn’t referenced anywhere (no link to it), so users won’t be able to get there after they log-in and click another link.

To make it available, you either have to provide a link to it on your portal’s homepage, or to add a new tab to the Dokeos navigation header. This however, is tricky, and I won’t cover it this time.

[3] Making the style fit to 800×600

There’s no secret recipe here. You have to try it and fix what’s to big to fit on screen. To help you, you can install the Web Developer extension for Firefox, which allows you to pick any dimension and resize your window to show you what it would look like on a 800×600 screen.

Although it may sound kind of “old fashion” to use 800×600 nowadays, I must admit that for very large administrations, it’s a nice feature to have as a low resolution also means larger fonts on screen, so you don’t annoy people with bad sight.