Defect #6392
closedUpdated/Created links to activity broken
100%
Description
All links I've found so far, after the update some minutes ago to the trunk, that are of the "x seconds/minutes/hours/months ago" type all link to /projects/activity/PROJECTNAME?from=DATE
instead of /projects/PROJECTNAME/activity?from=DATE
which results in a 403 error page (You are not authorized to access this page) although my user has all privileges possible.
Running Redmine 1.0.1.devel.4084 (MySQL)
Updated by Felix Schäfer about 14 years ago
I can confirm that, I'll try to have a look tonight.
Updated by Felix Schäfer about 14 years ago
I feel a little weird giving a link to github here, but the fix for that is here: http://github.com/thegcat/redmine/commit/6c2d9d79b6d60e683e3e65d45efdb3dcf54da379
Eric: tag, you're it.
Updated by Mischa The Evil about 14 years ago
Felix Schäfer wrote:
[...]the fix for that is here: http://github.com/thegcat/redmine/commit/6c2d9d79b6d60e683e3e65d45efdb3dcf54da379
I can confirm this issue too. It is introduced in r4047. The proposed fix works flawlessly.
Updated by Jean-Baptiste Barth about 14 years ago
- Status changed from New to Resolved
- Assignee changed from Eric Davis to Jean-Baptiste Barth
- Target version set to 1.0.2
- % Done changed from 0 to 100
- Resolution set to Fixed
Applied in r4092, thanks. I propose you assign this kind of really simple fixes to me, so that Eric can concentrate on great refactorings (I imagine his time is precious and we shouldn't waste it..). May I also suggest some of you ask commit bit to JPL ? It would be great for these kind of things at least.
Updated by Felix Schäfer about 14 years ago
Jean-Baptiste Barth wrote:
I propose you assign this kind of really simple fixes to me, so that Eric can concentrate on great refactorings (I imagine his time is precious and we shouldn't waste it..). May I also suggest some of you ask commit bit to JPL ? It would be great for these kind of things at least.
Well, I had discussed this with Eric on IRC and he was OK with it if I assigned this kind of small things his refactorings introduced to him (it was his fault after all ;-) ). If you say you're ok with applying them too, I could either just add both of you as watchers, whomever comes first can apply it, or even assign them directly to you.
Regarding commit rights: I wouldn't really mind, but I think pushing the changes to github so you can pull/cherry-pick them is just as good for now (at least if you use git too…). Do you use git or svn?
Updated by Jean-Baptiste Barth about 14 years ago
Felix Schäfer wrote:
Well, I had discussed this with Eric on IRC and he was OK with it if I assigned this kind of small things his refactorings introduced to him (it was his fault after all ;-) ). If you say you're ok with applying them too, I could either just add both of you as watchers, whomever comes first can apply it, or even assign them directly to you.
OK. Sorry I didn't know you already discussed it. As you want, I receive and read all tickets anyway. An explicit sentence in the note is perfect for me.
Regarding commit rights: I wouldn't really mind, but I think pushing the changes to github so you can pull/cherry-pick them is just as good for now (at least if you use git too…). Do you use git or svn?
Git (anybody uses SVN nowadays ?!?). I may be wrong, but I think it takes time to review, apply, (d)commit the patch, and finally update the ticket accordingly. If we have 5, 8, 10 committers, the workload is distributed, even if 1 or 2 leaders should still decide what to merge in stable branch. My 2 euro cents...
Updated by Felix Schäfer about 14 years ago
Jean-Baptiste Barth wrote:
Felix Schäfer wrote:
Well, I had discussed this with Eric on IRC and he was OK with it if I assigned this kind of small things his refactorings introduced to him (it was his fault after all ;-) ). If you say you're ok with applying them too, I could either just add both of you as watchers, whomever comes first can apply it, or even assign them directly to you.
OK. Sorry I didn't know you already discussed it. As you want, I receive and read all tickets anyway. An explicit sentence in the note is perfect for me.
Noted, then I'll have you as a target for small changes now ;-)
Regarding commit rights: I wouldn't really mind, but I think pushing the changes to github so you can pull/cherry-pick them is just as good for now (at least if you use git too…). Do you use git or svn?
Git (anybody uses SVN nowadays ?!?). I may be wrong, but I think it takes time to review, apply, (d)commit the patch, and finally update the ticket accordingly. If we have 5, 8, 10 committers, the workload is distributed, even if 1 or 2 leaders should still decide what to merge in stable branch. My 2 euro cents…
I'm fine with whatever suits Eric and you. I think I shouldn't be the one asking for the commit rights though, but rather that one or both of you tell JPLang who you think should get them. Anyway, let's switch to the forums if you want to discuss this more, I think we have polluted this ticket enough already :-)
Updated by Felix Schäfer about 14 years ago
JBB: and while we're at it: in r4092, you committed the file special_page_index.rhtml
to the root of the repository (well, to trunk/ in svn…), it doesn't need to be there ;-)
Updated by Jean-Baptiste Barth about 14 years ago
Damned. I'll fix it tonight, thanks..
Updated by Eric Davis about 14 years ago
Jean-Baptiste Barth wrote:
Git (anybody uses SVN nowadays ?!?). I may be wrong, but I think it takes time to review, apply, (d)commit the patch, and finally update the ticket accordingly. If we have 5, 8, 10 committers, the workload is distributed, even if 1 or 2 leaders should still decide what to merge in stable branch. My 2 euro cents...
I think we should discuss moving at least the patch application process to git(hub). Felix just posted his git repo there so I can now cherry-pick and commit easily. I don't care who applies the (reviewed) patch as long as it makes it back into svn and the issue is updated correctly (Target Version, Resolved, etc).
Updated by Eric Davis about 14 years ago
- Status changed from Resolved to Closed
Merged into 1.0-stable for release in 1.0.2