Silva Issue Tracker Archive: Issue1588

 This tracker has been migrated to Launchpad. Please post new messages at:
Title error in access screen
Priority bug Status testing
Superseder (list) Nosy List aaltepet, daniel, faassen, jasper, kitblake, wim (list)
Assigned To daniel Topics Silva-1.5, Silva-1.6, error (list)

Created on 2006-06-09.14:41:49 by aaltepet, last changed 2007-03-13.12:18:04 by daniel.

File nameUploadedTypeEdit Remove
r23543.diff daniel, 2007-02-27.12:24:05 text/x-patch
msg9262 (view) Author: daniel Date: 2007-03-13.12:18:04
I can't look at this right now.  For the records:

From my POV the problem is that the Five view needs to be looked up on the
content object.  Thus, the URL changes to point to the content object and strips
out the '/edit' part.  Now with a base tag in place, we can have all relative
links on that page still point to '/edit/name'.  If other parts of the page need
to link to the content object itself (like '@@minimum_role_submit' originally
did with '../@@minimum_role_submit'), we need them to point to the content
object via .absolute_url(), like '@@minimum_role_submit' does it now.

An alternative solution that comes to my mind, which would make base tag and
other hacks unnecessary, would be to redirect.  But that has the problem that we
cannot send a message along.  I'm not sure if messages (=feedback) can also be
stored in cookies or some such.
msg9250 (view) Author: kitblake Date: 2007-03-10.08:12:04
This isn't fixed. The checkin message said "Be extra careful about base href and
the form's action." We need to be more careful. :-) There are two problems. 

1. When you set an access restriction, a second button appears called "acquire
restriction". This submits to "@@acquire_minimum_role_submit:method", which via
zcml shunts to '/browser/'. So you'd have add the "base =
self.context.absolute_url() + '/edit'" code to that method too.

2. But once the access restriction has been applied and the access screen has a
base tag, the other forms 404. This is in fact the original problem that Andy
posted. There are three other forms. I started to make their actions
constructed, pointing to /edit/, and then realized this all may not be necessary.

I don't get Zope's base tagging behavior. It puts in a base tag if there isn't
one. But, if you're in API space, thus in the Silva backend, it doesn't do that.
But when you leave API space (by triggerring #1 and going into Five folders) it
*does* add one, messing everything up:
<base href="http://localhost:8081/silva/%40%40acquire_minimum_role_submit/" />

Maybe we need to be less careful. Can't we just set a base tag for all screens
in the backend, meaning all those that are in /edit API space? I tried adding
this to macro_index:
<base tal:attributes="href string:${model/absolute_url}/edit/" />

And it seems to work. When editing, you always want to be in API space, even
when calling Five code from forms, which need an action of .. to get you up a
level so the Five folders can be found. 

I've tested the access screen and the others, so I'm checking in the template
changes to the head. But we should test whether having a base tag in all the
Silva backend screens has any other effects. Daniel, I haven't reverted
/browser/ (in case we need to be more careful :-)).
msg9240 (view) Author: daniel Date: 2007-03-08.15:00:00
I believe I fixed this for good now in r23781
msg9235 (view) Author: wim Date: 2007-03-08.11:56:55
Patrtially fixed:
If you change the restriction you can now use the other tabs without erroring,
but now it goes up one level to high if you change the restriction again in the
access tab without going to the other tabs.
Site Error
An error was encountered while publishing this resource.
Resource not found
Sorry, the requested resource does not exist.
Check the URL and try again.
Resource: @@minimum_role_submit POST

Troubleshooting Suggestions

    * The URL may be incorrect.
    * The parameters passed to this resource may be incorrect.
    * A resource that this resource relies on may be encountering an error.

For more detailed information about the error, please refer to error log.

If the error persists please contact the site maintainer. Thank you for your
msg9227 (view) Author: daniel Date: 2007-02-27.12:24:05
Attached the diff of r23534.
msg9222 (view) Author: daniel Date: 2007-02-26.13:47:29
Fixed in r23543.

Kit, can you please look at the fix and tell me if you think this is the right
way to do it?
msg8737 (view) Author: kitblake Date: 2006-09-22.10:23:39
Martijn, this conundrum is sitting on your desk.
msg8618 (view) Author: kitblake Date: 2006-06-29.12:36:54
Forgot to make Wim – who's doing the fixing – nosy.
msg8617 (view) Author: kitblake Date: 2006-06-29.12:36:18
Umm, we have to reverse this fix. The '..' is needed to access a Five view. The
setting of access restrictions is broken with the '.', we get a 404.

This means the problem Andy described *could* happen, but that's better than a
broken Five view, because there's a workaround: re-access the page. I say
re-access because reload may trigger the cryptic browser alert: "The page you
are trying to view contains POSTDATA..." 

So, all operations can be carried out, but certain sequences may require that
the Access screen be re-accessed. 

Martijn is going to scratch his head on this one. :-)  Back to 'in-progress'....
msg8596 (view) Author: kitblake Date: 2006-06-17.22:13:18
Fixed in 1.5/trunk
msg8576 (view) Author: aaltepet Date: 2006-06-09.14:41:47
In Silva/views/edit/, Silva <HEAD>

This is a two-step bug, to replicate:

1) Change the public view access restriction to something other than the current
2) Notice the url now has /edit removed. (this is the problem!)
3) Any further actions on the page (that are relative urls) will probably break.
 I.e. you cannot change the public view restriction.

The issue is that the public view restriction form has an action of '..' (up one
level) and not '.'.
Date User Action Args
2007-03-13 12:18:04danielsetmessages: + msg9262
2007-03-10 08:12:05kitblakesetnosy: + jasper
messages: + msg9250
2007-03-08 15:00:02danielsetstatus: in-progress -> testing
assignedto: faassen -> daniel
messages: + msg9240
2007-03-08 11:57:04wimsetstatus: testing -> in-progress
2007-03-08 11:56:56wimsetmessages: + msg9235
2007-02-27 12:24:06danielsetfiles: + r23543.diff
nosy: + daniel
messages: + msg9227
2007-02-27 07:59:51kitblakesetnosy: + kitblake
2007-02-26 13:47:31danielsetstatus: deferred -> testing
messages: + msg9222
2006-11-06 11:47:53kitblakesetstatus: in-progress -> deferred
2006-09-22 10:23:40kitblakesetmessages: + msg8737
2006-09-04 11:57:58faassensettopic: + Silva-1.6
2006-06-29 13:48:19wimlinkissue1596 superseder
2006-06-29 12:36:54kitblakesetnosy: + wim
messages: + msg8618
2006-06-29 12:36:19kitblakesetstatus: testing -> in-progress
messages: + msg8617
2006-06-17 22:13:19kitblakesetstatus: unread -> testing
messages: + msg8596
title: error in access tab -> error in access screen
2006-06-09 14:41:50aaltepetcreate