[6.1 trunk] [project] confusing features - improvement suggestions

Hello,

Yes, I am agree with you regarding improvement in project. As per my opinion this issue needs more clarification for new implementation,for now It needed lot of changes regarding the improvement what you suggested in bug specification. currently I am setting this issue as wishlist.

Thanks.

IMHO moving project to configuration is unexpected.

at the same time I would appreciate (as already mentioned very often) if project and task names get longer fields (colspan=4) to show the complete name on smaller screens.

Moving the creation of projects to the Configuration menu seems a really odd decision. I don't know of any other system that would take this approach and it should be moved back to how it was.

On Mon, Oct 31, 2011 at 2:49 PM, James Jesudason <
<email address hidden>> wrote:

> Moving the creation of projects to the Configuration menu seems a really
> odd decision. I don't know of any other system that would take this
> approach and it should be moved back to how it was.
>

+1

Also he issue is that we also need o quickly access the list of projects,
not just create new ones. Having them in the config section doesn't make
sense to me.

>
> --
> You received this bug notification because you are a member of OpenERP
> Committers, which is subscribed to OpenERP Addons.
> https://bugs.launchpad.net/bugs/882528
>
> Title:
> [6.1 trunk] [project] confusing features - improvement suggestions
>
> Status in OpenERP Addons (modules):
> Confirmed
>
> Bug description:
> Hello,
>
> I would like to underline some confusing features in the [project]
> module/addon.
>
> 1. Since a few revs, the Project->Project->Project menu changed to
> Project->Configuration->Project. I think that 'Configuration' menu
> items should be used for setting the meta-data (data about the data -
> types, categories, periods, &c.) and not for "real" data.
>
> 2. Tasks hierarchy : there is a straightforward feature of parent-
> child relationship for tasks. However, the view lacks clarity:
>
> - for a parent task, the work done in a child task should be presented
> under the 'Work' tree maybe as:
> (child) task | summary | user_id and so on
>
> - for a child/independent task, the same should be seen, but without
> the task name (as is today). BTW, some info, as 'project' is
> redundant, as I see no use of listing tasks from different projects.
>
> - in the second tab (Delegations) two different concepts are mixed:
> hierarchy and delegations. While the first area (parent task) works as
> expected, I think the "delegated tasks' could be improved; there is no
> difference between 'delegated' and 'child' tasks. And it should be.
>
> The way I see 'hierarchy' - meaning a parent contains all children
> (parent work = sum of children work) shall also be differentiated from
> 'dependency' meaning that one task depends on the completion of
> another (like delegated task - check).
>
> In the project module, 'delegation' contains 'dependency', however
> there is no way to set 'dependency' besides 'delegation'.
>
> To conclude, I think that:
> - parent task should be a real "container", which shall adapt / put
> constraints on its children (time, costs, &c.)
> - parent work should show sum of children work
> - 'Delegations' tab should be called 'hierarchy' and show only
> parent-child relationships (not 'delegated' tasks, even if today they are
> also children- why?? a delegated task changed its initial assignee, and an
> additional check task is dependent on its completion)
> - dependence (Start B if A is completed) should be available for any task
> not only for delegated-check pairs.
> - hierarchy, delegation and dependency are three different basic concepts
> which should be implemented separately in the module (and not as additional
> modules).
>
>
> If this is not the right place for this, I do apologise in advance.
>
> Thank you,
> ...

The organization of a project is not natural for new users. Most newcomers are used to work with MS-Project or alikes products, and thus the first approach is to think in projects and interrelated tasks, where dependencies among tasks are defined at the task level.
The two path approach of OpenERP (Projects with tasks OR projects with phases and tasks, with different schedule methods and additional object like project phases) is counter-intuitive
In memory project managers use to reschedule and compute on the fly dates whenever the user change task status or dependencies. Perhaps on OpenERP is technically difficult to get this kind of response, but at least rescheduling should be handled on the project form, whithout different paths for project with phases and projects with just tasks.
Additionally, it seems counterintuitive not to have programed start and end dates on tasks lists. For the user is most of the time the only important information to watch.
It is also to note that with the current approach of navigation, in the case you have a list of several projects with many tasks, whenever you change from project to tasks or when you are assigning task dependencies, you loose the domain information, and thus you keep entering the project name in the search view to keep the list at an usable size

+1