ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Be able to change defaults fields (Feature #902)

Added by guilhem lettron at 2012-02-23 02:02 pm. Updated at 2013-02-02 01:20 am.

Status:Open Start date:2012-02-23
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:-
Target version:-
Remote issue URL: Affected version:

Description

For the moment, defaults fields like "begin", "end", "time estimated" ... cannot be remove.

But many times, we use ChiliProject for non-developing task, this fields are useless and worst it can be confusing.

[mumbo-jumbo]
In my point of view, ChiliProject must be a generic project / team manager. Developing is one of the usage (the most use of course).
I will be happy to talk with someone from the project to share some experience / vision.
[/mumbo-jumbo]

History

#1
Updated by Kris Lou at 2012-02-23 06:57 pm

I agree. Perhaps "Time Estimated" could be toggled based on whether or not the Time-Tracking module were enabled . . .

However, I do believe that Begin and End are pretty much essential.

#2
Updated by guilhem lettron at 2012-02-24 11:31 am

Begin and End are essential in your way of using this software. But you aren't everybody.
For example : I was using CP to organise meeting. priority, begin, assign to was useless. More problematic, it was a source of problem with some persons who call the IT team because "software asking for something that I don't have".

So, in my point of view ALL fields must be configurable, because we don't know how this software will be use. But default options must be the same as now (what is the most use and the most useful in many case)

#3
Updated by Wiki Bit at 2013-02-01 10:32 am

vote +1 from me
the ability to disable (or maybe just hide??) unused fields can avoid confusion with users also

#4
Updated by Chris Dähn at 2013-02-02 01:20 am

Disabling some fields by config would be nice - we for example don't use the "category" or "version" fields for some projects - where these fields often lead to confusion.

This is a good task for a plugin (so it would be as flexible as possible).

Here some other tickets with comparable requests or which could be realized together:

  • Powerfull workflow field enhancement: visible, read only and mandatory depending on role and current status (Feature #1166)
  • Automatically detect required and optional fields in a form (Feature #208)
    => ok, this is a task for the Core-Devevlopment
  • Multiselect custom fields (Feature #141)

Also available in: Atom PDF