Posted by JimWebb on May 7, 2010 at 3:54am
12 followers
| Project: | Content moderation |
| Version: | 6.x-1.9 |
| Component: | User interface |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
Steps to reproduce
1. Create a node with revision moderation.
2. Do a state transition without a new revision.
3. User is redirected to node/[node]/revisions page, which shows "Access Denied"
This works ok if a new revision is created before a state transition.
Comments
#1
How should this be related to content_moderation?
content_moderation is not providing the node/%/revisions callback, neither changin it AFAIK.
#2
This breaks UI flow since user would see an error page even if transition is successful. It would make sense to change any links/redirects to node/[node] instead of node/[node]/revisions in cases when only one revision is present.
#3
Well wait iam getting confused.
I expect that you: Forgot to give the user the permission to show revisions.
If you then click on "revisions" and get a "access denied" this is to be expected. I cant change the behavior of the core?
Iam pretty sure i must miss somthing, could you rephrase
#4
The revisions are accessible if there's more than one revision. Also, I'm logged in as drupal admin. Can you reproduce this problem? If not, it maybe that there's something wrong with my drupal setup.
#5
I will investigate, thanks for reporting back
#6
Hi,
I do have the same behavior here, doing all operations under admin user :
"Access denied" on node/NID/revisions/VID/view page (which is the link of the "view" button in the "Revisions" block).
I Found some info at http://drupal.org/node/138454, it seems that "view" links should point to node/NID when there's only one revision for the node, instead of node/NID/revisions/VID/view.
#7
thank you cryxair. sounds reasonable. I did not find the time to look into this yet
#8
Same to me. I've installed a completly new drupal site (6.17) and content moderation as the only additional module. Createing a new page, a klick to the "eye" icon and voila-> "Access denied. The revisions state has been successfully updated to review" and "You are not authorized to access this page". I've got also two icons on the moderation block...
#9
Iam currently running low on time. Anybody volunteers to look into that?
#10
We are having this issue as well. Here is a patch to fix the 1.4 release. I'm pretty sure I got everything.
ignore this, i found a few more instances... see this post
#11
devkinec thank you very much for the contribution, i will look into the patch shortly.
#12
Alright, here is a working patch based off of the current 1.4 drupal.org release.
I created a new function to determine whether or not the revision being linked to is the only one in existence. Also, the function is flexible enough to work with the module's integration with the diff module.
This is in production on my site.
#13
whoops sorry about that I overwrote your status changes.
And your very welcome, this module has some great potential and is really a mission critical feature for many organizations.
#14
We are currently using this module for a client and applied the patch above. This fixed the issue for revisions giving an access denied but unfortunately a new issue popped up. When the function counts revisions and there is only one then the url is changed to the drupal path. This causes an issue if there is a live version and one revision. In this case the live version is fine but the first revision points to the live as well. I created a quick patch to test for this case and change the url if there is only one revision and no live version. The patch combines the 792202.patch with this additional check and a quick change to an output message that leaves the e off of the word therefore.
#15
Here is the patch for those how have already applied the 792202.patch
#16
thanks, I didn't think of that case when i did the original patch. I added yours from #15 and that worked great.
Newcomers, if you are looking for a patch #14 is the way to go.
#17
Thanks for the work guys, i will have a look at it ASAP!
#18
I had the same issue and the patch in #14 does indeed seem to solve it, Thanks! But I think you also need to change the URL for the 'cancel' button on the form. This still takes you to a URL with /revision so you still get the access denied message.
Hope this is clear: the user creates a new node, then clicks the eyeball to change the state, but clicks cancel on the form instead of submitting it.
Cheers.
#19
Did not include this into 1.5 as i did not have enaugh time. Want to bringt that one into 1.6 ASAP. Thanks for your work!
#20
Anyone have a 1.5 version of this patch?
#21
dont hesitate, thats not a official paid support forum. 1.6 will come ASAP, i think in the next 2 days. We have a urgent "dsm" bug and this one to fix.
#22
How is 1.6 coming along? The simplicity of this module is very appealing, but I keep getting the access denied message on Revisions :(
#23
Iam sorry for the delay. Iam not gone, but pretty busy. I will try to catch up with this that weekend and that release should be out then.
#24
patch wanst complete by far, but was a good start. I added all the other places. Will care about the cancel button also.
#25
#26
Automatically closed -- issue fixed for 2 weeks with no activity.
#27
I am using the 6.1.9 version of the module and am experiencing the same access denied issue for the revision menu path.
The only way around this that I have found it is to fire a triggered rule when submitting a revision to redirect to the node path.
example: node/431/revisions/478
returns an access denied as the author and even user 1 gets access denied.
#28
#29
Its default drupal functionality to display an access denied on a node when there is only one revision. The issue in this thread is related to the module trying to use those pages on nodes that only have one revision.
If you have the latest release, and are still seeing these pages crop up, please detail what you were doing and what you clicked on to reproduce the error page.
#30
Well before we continue here, we need more informations. Thanks for clarifying devkinetic
#31
Hey all.
I've just spent most of the morning working on this. From what I'm seeing, while the node/%node/revisions/%/view path is used in a number of places it's only causing this issue in one and that's the drupal_goto()s around line 101 of content_moderation.workflow.inc.
I tracked back through to node.module to find out why it's denying access and found that this is the standard behavior if attempting to view a revision and it's the current version of the node. I've nicked a few lines from there to perform the same test and point at node/[nid] if viewing the revision would result in access denied.
I checked out the other patches and there appears to be a lot more in them than this one. I couldn't see the need for these extra changes though. If someone can give me a usecase that shows the need for these other changes that'd be appreciated. As it stands this patch addresses one aspect of the workflow.
Anyway before applying the patch this is what you get;
After applying the patch you land on the node/[nid] which you can actually see.
#32
Hi Gold,
thank you for your work.
What you describe is actually known to me / investigated the same issue back then. We introduced this issue back in times when we changed the way the revisions in the block are linked ( we generalized it ). We had reasons for this, there have been a bug arround this before.
Your patch looks pretty good, nothing to add. We have to find the older issue about the links to be sure we dont reintroduce a new bug or at least be sure we dont get side-effects.
Currently all my drupal modules are outdated, a lot of patches waiting in the queue. Iam pretty sorry, but i cant get any freetime to work on all those right now and cant find any co-maintainers
#33
I'm currently working for Sparks Interactive and we've got a number of clients that are needing this sort of thing. This module, while it can be a little complex to get working (did I miss some documentation maybe?) is the best option available from what we've seen.
I'll check with the boss and see if he's open to the idea of me being a co-maintainer. I'll at least be able to work on it during work hours. Like you, I'm quite pressed for time, but paid hours are a good thing. :)
If he's open to it and you're okay taking me on as a co-developer, would it be possible to get a sponsor link on the description page?
#34
Jan's eyes lit up when I suggested this to him. Mainly, I think, due to the ability to be able to run a -dev status module with a bit of confidence. :)
So yeah, if you want a co-maintainer I'm willing and able to step up.
#35
In the meantime, given that #31 only addresses a very specific issue, if we could get a couple of others to test it and offer feedback that would be great. If Eugen takes me on I'll get the patch in asap and get it out. This one thing was the main bugbear that we had with respect to progressing with this module.
I'll also see about getting a few hours a week for dedicating to the clearing of the current patch backlog too.
#36
Thats sounds great!
Are you arround in IRC to chat a bit about organisational stuff?
#37
Hey Eugen,
I will be around early tomorrow AM. I'm in New Zealand and "tomorrow AM" is about 18 hours from the timestamp on this post. :)
There's a number of items on my worklist here for content moderation. I'll talk over them with you tomorrow though. I'll also check over the patch/feature list and see if anything I have is already on the list.
#38
Hello Eugen,
I've started getting my head around github. Enough to push back to it at least.
I've created a fork of the project and have pushed the above patch back;
https://github.com/Unifex/content_moderation
From what I've read I think I'm doing this right. Let me know if there's some thing that I'm doing wrong though. First time user with an active github account. Usually I'm just pulling projects down.
#39
Well its fine. We can now start to work with push request and alter work both on the EugenMayer/content_moderation project. So keep up the good work :)