Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Step to reproduce:
- OA 2.43 stock with Space (with Group as inherited member), Group and users configured
- Clean URLs test failed but Clean URLs is enabled and it is working as expected on the site
- Sitemap is normally accessible and content like Posts/Events/etc. (inside their existing Sections) can be created
- The action of adding a New Section through the Sitemap (using the "+" New Section button):
- Logged as the Site Admin -> doesn't show the issue
- Logged as a User:
- which is non Administrator member of a Group
- who has not an Editor role
- who is member of the inherited Group of the Private Space in which the test was done
-> do show the issue
- (OG Organic Group) OA Group's permissions let member users to create Sections: Create/Edit Section Page content and Delete own Section Page content are enabled.
- OA Wizard 2.1 Module is enabled and green (All modules required as its dependencies are available, enabled and green)
- After clicking OK on the AJAX Error Message pop up windows the Running Wheel is presented (with no apparent timeout).
This is the AJAX Message (redacted the site name with XXXXXXX) that appear to user:
An AJAX HTTP error occurred.
HTTP Result Code: 403
Debugging information follows.
Path: /api/oa_wizard/section-wizard?og_group_ref=74
StatusText: Forbidden
ResponseText:
Access Denied | XXXXXXX
document.createElement('header');
document.createElement('nav');
document.createElement('section');
document.createElement('article');
document.createElement('aside');
document.createElement('footer');
Skip to main content
Toggle navigation
Toggle navigation
Toggle navigation
Toggle navigation
Backoffice
Helpdesk
Home
Public SpacesSite map
Spaces
User Two
Dashboard
Edit profile
Log out
Search Button
Search Options
All spaces
This space
Users
×Unable to load wizard
Access Denied
You are not authorized to access this page.
Powered by
These two httpd access_log lines (one GET and one subsequent POST) are generated by the AJAX Error when it pops up (unredacted):
192.168.0.10 - - [03/Sep/2015:11:17:06 +0200] "GET /profiles/openatrium/modules/panopoly/panopoly_magic/images/status-active.gif HTTP/1.1" 304 - "http://intra.servers.lan/sites/default/files/css/css_LoUrilq8CLZ6gRVD0fS2Gopz7CkL4A-zYd2U25Rxm2Y.css" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0"
192.168.0.10 - - [03/Sep/2015:11:17:06 +0200] "POST /api/oa_wizard/section-wizard?og_group_ref=74 HTTP/1.1" 403 25641 "http://intra.servers.lan/sitemap" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0"
Am I missing something simple but important?
Comment | File | Size | Author |
---|
Comments
Comment #2
dpoletto CreditAttribution: dpoletto commentedComment #3
mpotter CreditAttribution: mpotter commentedI believe this was already fixed in the 2.44 update, so please always be sure to test in the latest version. Re-open if this is still an issue in v2.44.
Comment #4
dpoletto CreditAttribution: dpoletto commented@mpotter: re-opened because on the site I'm using for testing (upgraded today from OA 2.43 to 2.44) the behaviour I described above looks exactly the same.
Comment #5
joevagyok CreditAttribution: joevagyok commentedI'm on the actual version and I'm experiencing similar problem, please see my attachment!
I got the full form in the modal, without the horizontal tabs, as before.
After clicking on close and opening again, nothing is loaded, page need to be refreshed.
Comment #6
mpotter CreditAttribution: mpotter commentedYou need to look in your browser Console log to see if you are getting any javascript errors. Javascript is responsible for hiding the fields and making it look like a wizard. So if javascript is failing then you'll get that full form.
The fact that the OP says Clean URLs were showing an error might be a problem as ajax requires correct clean url handling.
But I just ran the procedure in the OP here and cannot reproduce this problem on any of our servers.
Comment #7
dpoletto CreditAttribution: dpoletto commentedNot sure if it is something really related to Clean URLs (if so, Clean URLs should create problem also as Administrator, a case that doesn't happen and the site seems to run quite normally): maybe it's a permission issue, but what?
While reproducing the AJAX Error my web browser's console (on a Firefox 40.0.3) shows an "HTTP/1.1 403 Forbidden" on:
http://intra.servers.lan/api/oa_wizard/section-wizard?og_group_ref=2
where the number 2 is the Space on which, on the Sitemap, actually I'm try to add a new Section via the "+" pushbutton.
If I go on that URL directly the page loads and shows the Error message "Unable to load wizard" and, below, the "Access Denied You are not authorized to access this page." message both related to the Forbidden error reported above.
Now the news: I noticed that if I *first* go to the Space 2 and there I add a Section via the "Create new section" toolbar menu without finalizing the action and I then come back to the Sitemap to select the "+" (New Section) now it just works as expected (no more AJAX Error) and finally I can see the "Add New Section Page" instead of the Gear icon running after the Error message.
It's like there is the need to cache something before...
Comment #8
mpotter CreditAttribution: mpotter commentedAhh, that makes more sense. Yes, you need to first be in the space that you are creating the section for. The current space is stored in your browser session and that's what is used by the wizard to set access.
Comment #9
dpoletto CreditAttribution: dpoletto commentedHi Mike, thanks for you support.
The user *is* (or he/she thinks to be yet) into the Space once that Space is browsed/selected on the Sitemap (indeed the user sees Sections yet available on that Space): please suppose the first thing a logged user does is to go to the Sitemap then he/she selects and enters the Space and, only then, once he/she is inside it (on the Sitemap page), he/she decides to add a new Section with "+" in that specific Space he/she selected.
I think it is a quite normal workflow.
I mean: it should not be necessary to visit *that* Space - without using the Sitemap - before...to complete the Section addition. Am I missing something?
Comment #10
joevagyok CreditAttribution: joevagyok commentedI think my problem is slightly different from the reported, because the ajax works, the section creation form loaded, but the jQuery fails half way, so I wouldn't open a similar discussion.
In my case I receive a jQuery error:
Uncaught Error: Syntax error, unrecognized expression: #/space/38
So the code receives the current space ID to create the section there.
Comment #11
mpotter CreditAttribution: mpotter commentedI believe that jQuery error is caused when you have other tabs on the page and might be related to the patch fix here: #2426513: Hash usage in radix-script.js breaks with use of a hash map in URL.
Back to this specific issue in #9, Can you post a specific procedure for reproducing this? I tried your workflow and still didn't get the ajax error, so I must not be using your exact steps. Your workflow sounds fine.
Comment #12
dpoletto CreditAttribution: dpoletto commentedWith the aforementioned initial conditions reported above (especially the fact that testing user is an Indirect Member of the Spaces although is able to create new Sections directly):
The AJAX HTTP Error shows up.
If, before attempting Step (6), the same user visits the Space into which the desired new Section should be created, then, once back to the Sitemap page, if he/she repeats the procedure from Step (2) or (3) finally a new Section can be created normally and no errors show up.
It's definitely something about permissions (but what?) when the action is performed by *that* type of user *and* when the described procedure is tried *only* from the Sitemap without ever visiting Space directly.
Comment #13
mpotter CreditAttribution: mpotter commentedSo I still couldn't reproduce this. My guess is you are still missing some permission. Please describe exactly how the permissions for both the Space and the Group the user is in have been changed from the defaults. Also, any changes to the global Drupal permissions.
Maybe you could spin up a Pantheon test site (getpantheon.com/openatrium) and then email me the user and admin logins that show this problem? But this is getting pretty far down the custom site support path so there is going to be a limit to how much I can do for you on this.
If somebody else could reproduce this problem on a clean Atrium install that would also be useful. I can help more if it's a general Atrium problem rather than something site-specific.
Comment #14
dpoletto CreditAttribution: dpoletto commentedWell, I'm sad (for being unable to diagnose what happened) and sorry (for wasting your time)...today it works as expected! Grrrrr...
I cleared the Cache and I did rebuild Permissions but I'm sure I didn't change any value regarding the Group Permissions, indeed the Group used for test:
Regarding the Organic Group permissions for member role:
So I'm a little bit confused *but* it works now. I suspect there is the Clear Caches and Rebuild Permissions magic in between...
A thing I still notice (but I didn't reported because I thought it was a minor issue at time) is that, after creating a new Sections through the Sitemap "+" New Section action, this new Section is reported on the Sitemap three times (example: I add a Discussion Section called "Tricks" and it shows "Tricks" three times - I mean three icons - but if I refresh the web page the result is the expected one "Tricks" Section icon to appear).
Very strange (It too happens on OA 2.43 that didn't suffered from this AJAX HTTP magic issue).