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?

CommentFileSizeAuthor
#5 2015-09-10_172415.png34.42 KBjoevagyok
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dpoletto created an issue. See original summary.

dpoletto’s picture

Title: Adding New Section from Sitemap generates an AJAX Http error (403). » Adding New Section from Sitemap generates an AJAX HTTP error (403).
mpotter’s picture

Status: Active » Fixed

I 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.

dpoletto’s picture

Version: 7.x-2.43 » 7.x-2.44
Status: Fixed » Active

@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.

joevagyok’s picture

FileSize
34.42 KB

I'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.

mpotter’s picture

Status: Active » Postponed (maintainer needs more info)

You 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.

dpoletto’s picture

Not 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...

mpotter’s picture

Ahh, 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.

dpoletto’s picture

Hi 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?

joevagyok’s picture

I 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.

mpotter’s picture

I 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.

dpoletto’s picture

With 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):

  1. Login a user
  2. On Toolbar browse Spaces -> select drop-down icon to Site map menu link OR browse Home -> select drop-down icon to Site map menu link
  3. Site Map is reached and it shows existing Spaces
  4. Select an existing Space
  5. Site Map shows Sections inside the Space
  6. Select "+" (New Section) to add a new Section to existing ones

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.

mpotter’s picture

So 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.

dpoletto’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Well, 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:

  • has Groups user inheritance set to Yes
  • has Group user permission inheritance set to Inherit Permissions
  • has Group roles and permissions set to Override default roles and permissions
  • is inherited member of the Space used for test
  • has the user used for test added as non Group's Administrator member (user hasn't the Editor role)

Regarding the Organic Group permissions for member role:

  • Group's permissions (those Overridden) has -> Organic Groups: Create Section Page content enabled for member role.
  • While Node - Group permissions on OG Permissions has -> Organic Groups: Create Section Page content disabled for member role (which is default AFAIK).

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).