Item10822: Ajax-Interface: Handling of WikiGuest / unauthorized access

When viewing a table as WikiGuest and then trying to edit a single cell, the log-in dialog gets displayed in this very table cell. Looks nasty. The modification gets saved, but the redirection after log-in is broken.

• Maybe it would be best to hide all editing features if the current user doesn't have write permissions?!
• Or instead of hiding, the invocation of a single-cell edit should rather forward the user to the log-in screen and afterwards send him back to the original topic for editing the cell.

Setting priority to "normal", but feel free to change it...

-- PhilippLeufke - 01 Jun 2011

If the current user doesn't have CHANGE access to the topic, then none of the edit features are displayed. What rights does WikiGuest have to the topic?

-- CrawfordCurrie - 03 Jun 2011

Well, WikiGuest doesn't have editing rights, that's why a not logged-in user (WikiGuest) currently gets forwarded to the log-in dialog after he tried to edit a table field.

Changing of the topic I'm talking of is not allowed to WikiGuest. Trying to edit the topic results in the log-in dialog, as it should.

And yet, the edit features of the table are definitely visible for WikiGuest in my case, using the most recent EditRowPlugin.

-- PhilippLeufke - 03 Jun 2011

Yeah, I see now that it's a special case for wikiguest. Well, there has to be some way to prompt with a login, and there's no clean way to redirect the page in an XHR callback that I can find, so there's no choice but to do the prompt in the cell. There is definitely a problem though when saving on.

Similar issue applies when moving rows from a non-0auth starting point.

-- CrawfordCurrie - 03 Jun 2011

Commenting is disabled while not logged in