Defect #21056
closedProject specific TimeEntryActivity name not updating properly
0%
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
Related issues
Updated by Stephane Evr almost 9 years ago
Affected version is 3.1.0 (Not tested on 3.1.1)
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.
Updated by Toshi MARUYAMA over 8 years ago
- Affected version changed from 3.1.1 to 3.1.0
Updated by Toshi MARUYAMA over 8 years ago
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.
Updated by Stephane Evr over 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.
Updated by Stephane Evr over 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...
Updated by Stephane Evr over 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
Updated by Toshi MARUYAMA over 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
Updated by Toshi MARUYAMA over 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
Updated by Toshi MARUYAMA over 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
Updated by Toshi MARUYAMA over 8 years ago
- Related to Defect #20018: Duplicate activities in time entry report when project-specific activies exist added
Updated by Toshi MARUYAMA over 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)
Updated by Stephane Evr almost 8 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
Updated by Marius BĂLTEANU about 7 years ago
The issue still reproduces on 3.4.1.
Updated by Sébastien Douheret about 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.
Updated by Mizuki ISHIKAWA about 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)
Updated by Mizuki ISHIKAWA about 3 years ago
- File diff-v2.patch diff-v2.patch added
I fixed it because it contained unnecessary code.
Updated by Go MAEDA about 3 years ago
- Target version set to Candidate for next major release
Updated by Go MAEDA about 3 years ago
- Target version changed from Candidate for next major release to 5.0.0
Setting the target version to 5.0.0.
Updated by Go MAEDA about 3 years ago
- Status changed from Confirmed to Closed
- Assignee set to Go MAEDA
- Resolution set to Fixed
Committed the patch. Thank you for fixing the issue.