Defect #21056
Project specific TimeEntryActivity name not updating properly
Status: | Closed | Start date: | ||
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | % Done: | 0% | ||
Category: | Time tracking | |||
Target version: | 5.0.0 | |||
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...
Related issues
Associated revisions
Project specific TimeEntryActivity name not updating properly (#21056).
Patch by Mizuki ISHIKAWA.
History
#1
Updated by Stephane Evr over 6 years ago
Affected version is 3.1.0 (Not tested on 3.1.1)
#2
Updated by Toshi MARUYAMA over 6 years ago
- Status changed from New to Needs feedback
I cannot reproduce.
Project setting page uses tabs, so you need to reload this page.
#3
Updated by Toshi MARUYAMA over 6 years ago
- Affected version changed from 3.1.1 to 3.1.0
#4
Updated by Toshi MARUYAMA over 6 years ago
#5
Updated by Stephane Evr over 6 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.
#6
Updated by Stephane Evr over 6 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.
#7
Updated by Stephane Evr over 6 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...
#8
Updated by Stephane Evr over 6 years ago
#20018 Is a consequence of this issue
#9
Updated by Toshi MARUYAMA about 6 years ago
See Submissions.
#10
Updated by Stephane Evr about 6 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
#11
Updated by Toshi MARUYAMA about 6 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
#12
Updated by Toshi MARUYAMA about 6 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
#13
Updated by Toshi MARUYAMA about 6 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
#14
Updated by Toshi MARUYAMA about 6 years ago
- Related to Defect #20018: Duplicate activities in time entry report when project-specific activies exist added
#15
Updated by Toshi MARUYAMA about 6 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)
#16
Updated by Stephane Evr over 5 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
#17
Updated by Marius BALTEANU almost 5 years ago
The issue still reproduces on 3.4.1.
#18
Updated by Sébastien Douheret about 1 year 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.
#19
Updated by Mizuki ISHIKAWA about 1 year ago
- File 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)
#20
Updated by Mizuki ISHIKAWA about 1 year ago
- File diff-v2.patch
added
I fixed it because it contained unnecessary code.
#21
Updated by Go MAEDA about 1 year ago
- Target version set to Candidate for next major release
#22
Updated by Go MAEDA about 1 year ago
- Target version changed from Candidate for next major release to 5.0.0
Setting the target version to 5.0.0.