https://frontaccounting.com/punbb/viewtopic.php?pid=24867

With this method there is no need for extensive changes to the core just to implement a theme.

The file includes/menu.inc does not exist in both FA v2.3.x and FA v2.4.

The table 0_menu too does not exist in both versions.

It is possible you are using a very old or customised version of FA or it's fork or parent.

If you are using Drupal in the same folder and database you might encounter such an error.

Domain.PL dont work!

× DATABASE ERROR :
At file C:\wamp\www\faplanet-master\includes\menu.inc:15:
Cannot load menu from the database.
error code : 1146
error message : Table 'fa.0_menu' doesn't exist
sql that failed was : SELECT * FROM 0_menu WHERE menu='default'

THANK YOU

This looks very like PhreeBooks now !!! 

Check out their demo  (demo, demouser) -  http://www.phreebooks.com/pb-demo/index.php

You are speaking of UI "principles", but the first principle is probably "to make the user happy", the second , minimize the number of clicks. Your solution is adding  1 or 2 clicks to everything, I don't really see how it follows modern UI principles.

Also, the problem of "digging" under 2 or 3 level of submenu, features you don't use often is: you don't remember where they are and struggle to find them each time you need them.

What you proposed already exists, it was called OpenERP, and now Odoo apparently and as you said, you need 4 clicks to create a new customer (or pretty much everything in fact). I chosed FA vs OpenERP for that reason (and also because it was nightmare to find things in OpenERP).

The question is, why would peoble "buy" the new FA over Odoo ?
It's a bit like saying vim modes sucks, let's create a modeless vim to compete with emacs ... There a market for both editors and there is no need for 2 emacs.

In other, Don't fix it, if it ain't broken ...

/Elax

1. The new UI is indeed an attempt to sale, in a sense that to attract a group of users for which the current UI is not attractive. The size of this group is difficult to asses, but my guess (wild guess) is that as much as 50% of possible users could be lost. This does not mean of course that the current UI will be dropped.

2. I maintain that the current menu is clumsy and that can be measured. The changes to make it straightforward go beyond just the menu itself, so this is just the first and most important change. For example something that cryptic like "Delivery against sales order" should be turned into an "outstanding" "filter" in the "sales order view". In the same manner creating an invoice should be a "create" button in the invoice view, as it is now with customers (almost). It that sense "functionalities are grouped together". Anyway I understand your point, that is the point also why we use the linux console, which is a 1-level menu, but the majority of users do not use an OS like this. Again, this does not mean that the old menu should be dropped.

3. In Odoo you need more than 4 clicks to create an invoice, providing that the client is already there. I do not say it is a right solution, but my aim is to attract the most users possible, and your standpoint (@elax) represents expert users, so those needs exclude themselves. So it is perfectly understandable that you are unhappy with the changes.

4. The menu in its design is thought to be a 2-level, with the 3rd level being supportive only. The idea is that most important functionalities should be accessed by 2 clicks, but there is some work still to be done. This for example could be achieved by accessing the "direct invoice" directly when a user clicks "invoices", and add "transactions" as a separate entry in the "sales" menu. Anyway as proposed in point 2, I would prefer to focus on adding shortcuts than designing a "perfect" menu structure.

5. The point against adding a customer (by @elax) is a valid one but a proposed solution is a wrong. The proper solution is to add a popup menu with the possibility to add a customer in the "direct invoice" screen. By the way I wonder it has not been done yet, as it is an easy change. Following that way of thinking the screen "customers" would be for searching and only secondary for adding.

6. The "sales config" has been moved to the setup on purpose. The changes there are being made once in a blue moon so it is right to move that functionality deeper. What we care about are the most popular screens, the less popular are of course not so important.

7. The ubermenu is a cool idea although not a new one. I agree this could be a way to go, but for the moment what we have is enough, so it is unlikely I will put more effort into it.

My experience with customers is that they don't like that many items in menu. More experienced users have no issue with complicated menu.

I'm a user. I've been using FA several hours a day for years: 3 levels of depths in menu is too much.

Speaking of "customers" there is a difference between doing something "shinyY and  easy to "sell" to new customers and something which is easy and fast to use once people learn to use it.

A good example is animation when closing or opening windows (on window managers). It looks great, is super cool but after 30mn you just realize that waiting 2s to open a window just gets on the way.

If you really need flexibility for the menu, maybe it's better to have hooks that storing them in the db.
Anyway, maybe the solution is just mega menu (which is trendy ;-)).

/Elax

Moving menu scheme to database is right way to go. This approach gives maximum user interface design flexibility. I see no problem with implementing alternative menu layouts this way, giving ability to choose between current and arbitrary number of other menu layouts. The application performance should not suffer: the menu layout can be read form database once on user login and cached in session.

The proposed bootstrap theme is superious alternative for various mobile devices,  but is not so good for standard PC screen/kbd interface. But don't worry, we do not plan to abandon support for current, more conservative themes.

Janusz

Referring to elax's comments: menus can be customized