Defect #21056: Project specific TimeEntryActivity name not updating properly - Redmine

Custom queries

Documentation issues
Open defects
Open features
Patch queue
Plugin issues
Translation patches

Actions

Copy link

Defect #21056

closed

Project specific TimeEntryActivity name not updating properly

Added by Stephane Evr over 8 years ago. Updated almost 3 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Go MAEDA

Category:

Time tracking

Target version:

5.0.0

Start date:

Due date:

% Done:

Estimated time:

Resolution:

Fixed

Affected version:

3.2.2

Description

In Enumerations, create a new TimeEntryActivity with these settings:

Go in a project / settings / Activities (time tracking) the activity is listed properly:

Enable the activity, and save.

Then, in the Enumerations page, change the name of the activity and save.

Now, go back to project / settings / Activities (time tracking):

Expected: The name of the activity should be updated to the new name (Test B).

Note that I can force the update by clicking on the "Reset" button on the same page, but I then loose all of my other activities settings for the project...

Files

Download all files

enum_03.PNG (2.4 KB) enum_03.PNG		Stephane Evr, 2015-10-23 18:12
enum_04.PNG (6.86 KB) enum_04.PNG		Stephane Evr, 2015-10-23 18:12
enum_02.PNG (2.51 KB) enum_02.PNG		Stephane Evr, 2015-10-23 18:12
enum_01.PNG (7.66 KB) enum_01.PNG		Stephane Evr, 2015-10-23 18:12
diff.patch (3.01 KB) diff.patch		Mizuki ISHIKAWA, 2021-06-10 07:08
diff-v2.patch (2.53 KB) diff-v2.patch		Mizuki ISHIKAWA, 2021-06-10 07:22

Related issues

Related to Redmine - Defect #20018: Duplicate activities in time entry report when project-specific activies exist

Closed

Go MAEDA

Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Stephane Evr over 8 years ago

Affected version is 3.1.0 (Not tested on 3.1.1)

Actions

Copy link

Updated by Toshi MARUYAMA over 8 years ago

Status changed from New to Needs feedback

I cannot reproduce.
Project setting page uses tabs, so you need to reload this page.

Actions

Copy link

Updated by Toshi MARUYAMA over 8 years ago

Affected version changed from 3.1.1 to 3.1.0

Actions

Copy link

Updated by Toshi MARUYAMA over 8 years ago

Toshi MARUYAMA wrote:

I cannot reproduce.

On 3.1.2.

Actions

Copy link

Updated by Stephane Evr over 8 years ago

Toshi MARUYAMA wrote:

I cannot reproduce.
Project setting page uses tabs, so you need to reload this page.

Same problem after reloading the page, I will test with 3.1.2 to see if it is fixed.

Actions

Copy link

Updated by Stephane Evr about 8 years ago

Toshi MARUYAMA wrote:

Toshi MARUYAMA wrote:

I cannot reproduce.

On 3.1.2.

Could reproduce the issue on 3.2.1-stable... I followed exactly the steps as described.

Actions

Copy link

Updated by Stephane Evr about 8 years ago

Note that I think this issue is really annoying. This means that the projects will always keep the old activity names, resulting in discrepancies in the time entry activities reports...

Actions

Copy link

Updated by Stephane Evr about 8 years ago

#20018 Is a consequence of this issue

Actions

Copy link

Updated by Toshi MARUYAMA about 8 years ago

See Submissions.

Actions

Copy link

#10

Updated by Stephane Evr about 8 years ago

Toshi MARUYAMA wrote:

See Submissions.

Could reproduce the bug as described on a freshly launched Bitnami redmine demo instance (https://bitnami.com/launch/redmine/aws/now):

Environment:
  Redmine version                3.2.1.stable
  Ruby version                   2.1.8-p440 (2015-12-16) [x86_64-linux]
  Rails version                  4.2.5.2
  Environment                    production
  Database adapter               Mysql2
SCM:
  Subversion                     1.8.13
  Cvs                            1.12.13
  Git                            2.6.1
  Filesystem                     
Redmine plugins:
  no plugin installed

Actions

Copy link

#11

Updated by Toshi MARUYAMA almost 8 years ago

I still cannot reproduce on vanilla Redmine.


Environment:
  Redmine version                3.2.2.stable
  Ruby version                   2.1.8-p440 (2015-12-16) [x86_64-linux]
  Rails version                  4.2.5.2
  Environment                    production
  Database adapter               SQLite
SCM:
  Subversion                     1.6.11
  Darcs                          2.2.0
  Mercurial                      2.8.2
  Cvs                            1.12.13
  Bazaar                         2.1.1
  Git                            1.7.1
  Filesystem
Redmine plugins:
  no plugin installed

Actions

Copy link

#12

Updated by Toshi MARUYAMA almost 8 years ago

I still cannot reproduce on vanilla Redmine MySQL, too.

Environment:
  Redmine version                3.2.2.stable
  Ruby version                   2.1.8-p440 (2015-12-16) [x86_64-linux]
  Rails version                  4.2.5.2
  Environment                    production
  Database adapter               Mysql2
SCM:
  Subversion                     1.6.11
  Darcs                          2.2.0
  Mercurial                      2.8.2
  Cvs                            1.12.13
  Bazaar                         2.1.1
  Git                            1.7.1
  Filesystem
Redmine plugins:
  no plugin installed

Actions

Copy link

#13

Updated by Toshi MARUYAMA almost 8 years ago

Subject changed from TimeEntryActivity name not updating properly in project to Project specific TimeEntryActivity name not updating properly
Category changed from Administration to Time tracking
Status changed from Needs feedback to Confirmed
Affected version changed from 3.1.0 to 3.2.2

Actions

Copy link

#14

Updated by Toshi MARUYAMA almost 8 years ago

Related to Defect #20018: Duplicate activities in time entry report when project-specific activies exist added

Actions

Copy link

#15

Updated by Toshi MARUYAMA almost 8 years ago

mysql> select * from enumerations where name = "test0003";
+----+----------+----------+------------+-------------------+--------+------------+-----------+---------------+
| id | name     | position | is_default | type              | active | project_id | parent_id | position_name |
+----+----------+----------+------------+-------------------+--------+------------+-----------+---------------+
| 33 | test0003 |        6 |          0 | TimeEntryActivity |      0 |       NULL |      NULL | NULL          |
| 41 | test0003 |        6 |          0 | TimeEntryActivity |      1 |          1 |        33 | NULL          |
| 45 | test0003 |        6 |          0 | TimeEntryActivity |      1 |          2 |        33 | NULL          |
+----+----------+----------+------------+-------------------+--------+------------+-----------+---------------+
3 rows in set (0.00 sec)

Actions

Copy link

#16

Updated by Stephane Evr over 7 years ago

Could reproduce on:

Environment:
  Redmine version                3.3.0.stable
  Ruby version                   2.1.10-p492 (2016-04-01) [x86_64-linux]
  Rails version                  4.2.6
  Environment                    production
  Database adapter               Mysql2
SCM:
  Subversion                     1.9.4
  Cvs                            1.12.13
  Git                            2.7.4
  Filesystem                     
Redmine plugins:
  no plugin installed

Actions

Copy link

#17

Updated by Marius BĂLTEANU almost 7 years ago

The issue still reproduces on 3.4.1.

Actions

Copy link

#18

Updated by Sébastien Douheret almost 3 years ago

Problem still exists in 4.0.4 - stable.
Any change to have a fix or a workaround ?

What I don't understand, in my case some projects only use the system activities (IOW enumerations with parent_id = NULL) and other projects use duplicate activities (activities with parent_id != NULL).
Any explanation about system versus project activities logic in redmine is welcome, it will help me to understand and propose a fix.

Thanks in advance.

Actions

Copy link

#19

Updated by Mizuki ISHIKAWA almost 3 years ago

File diff.patch diff.patch added

Let's take the data of #21056#note-15 as an example.
"Administration> Enumerations> Activities (time tracking) New value" will create data like 33.
Then, when you save the settings for each project, data with project_id such as 41 or 45 will be generated.
I expect the 41 and 45 names to be updated when the 33 name is updated, but that's not really the case.

I have attached a patch that will automatically update 41 and 45 names when 33 name is updated.

Since the bug that the name is not updated has existed for a long time, it is possible that there is a project that has been used for a long time without being renamed.
I thought that it might be a problem if I change it suddenly with this change, so I try not to update the ones whose names are already inconsistent.(name: self.name_before_last_save)

Actions

Copy link

#20