Here are the most questionable changes we intend to make to Savane on
CERN branch:
- STATUS -> OPEN
The current "Status" field will be renamed into "Open". As a pure
boolean, it's value will be "True" or "False".
This change is cosmetic. It will make the whole interface more
coherent, but it has no effect in the code itself.
- RESOLUTION -> STATUS
The current "Resolution" field will be renamed in "Status". It is
also a change that will not impact the code.
In the first time, it may confuse some users. But users will be
warned and it should be easy for them to get used to this new
name.Moreover, the interface will be easier to
understand for newcomers.
- PRIVATE
The current "Private" field have two values that will be renamed
to "True" and "False" for cohesion with the field now named "Open".
The behavior and usage of this field is for most part very similar
to the "Open" field behavior and usage.
- ACCESS TO PRIVATE ITEMS
Currently access to private item is granted to anybody that is
member of a project.
It will be changed as boolean flag similar to project admin.
configuration.
- EXTENSION OF FIELD VALUE TRANSITIONS
Field transition as implemented by Yves Perrin permit to reassign
an item to a specific user depending of the transition being made.
* It will be extended so it permits also to change the "Open" and
"Private" field.
Sample use cases:
Item goes private if it is set to category "Security"
Item goes private if it is set to severity "Security"
Item goes closed if it is set to status "Fixed"
* It must be checked whether transition automatic changes are
applied at item registration, and not only during update.
* The more sensible approach to deal with configuration conflict
is to let the new extension override the basic configuration.
It means that if status "Fixed" close an item, anybody allowed to
set the status as "Fixed" is allowed to change the "Open" field
status to closed.
Projects that wants only Tracker Manager to be able to change that
should not set transition to automatically close items.
Not following this approach would probably make usage of the trackers
a nightmare each time to configuration are at conflict.
For instance, a tracker manager may well disallow non-members to set
item as "Private": but he may want at the same time that any item
that is set to category "Security" is set to private automatically,
whoever is the person updating the item. So it make sense to override
the basic transition setting (disallow changing privacy setting) with
the more advanced and automatic one.
Once Alberto Aimar approve these items, we will post them on the appropriate
tracker and proceed to the implementation.
--
Mathieu Roy
+
| Thalie : <http://yeupou.coleumes.org/>
| Clio : <http://clio.coleumes.org/>
| Uranie : <http://alberich.coleumes.org/>
| Euterpe : <http://kromaniaks.coleumes.org/>
+-----------------------------------------------------------+
