7956 Posts in 1394 Topics by 945 members
|Go to End||Next >|
13 July 2010 at 10:17pm Last edited: 13 July 2010 10:20pm
Bug with FileDataObjectManager and importing files (in IE), getting CSRF attack error because SecurityID was not posted.
14 July 2010 at 2:21am
Nice! I've been trying to track that one down!
14 July 2010 at 5:50am
When you edit an Album in ImageGallery and choose to Replace Cover Image, the From File Store option only ever lists folders and never any files. Surely this is a bug?
24 July 2010 at 3:55am
I'm having a problem with the Image DOM, It appears to have issues accessing Directory with a dash (-) in the name. The files in that dir are accessible from the rest of the CMS, and if I move them to directory without a dash in the name they're accessible from the DOM.
Firebug reports a 500 error when I try to access those directories. Its not a critical bug (I can just change the naming structure), but I thought you should know. I'm running on MAMP right now, I haven't rolled the site out to my full testing server yet.
24 July 2010 at 4:26am
What do you mean by "accessible from DOM?"
24 July 2010 at 4:43am
I'm setting Internal Server Errors when trying to access certain folders through the "Import from an existing folder" dropdown in a nested ImageDataObjectManager. However if I try to add images from those folders through the standard HTMLEditor field, I have no problems
29 July 2010 at 1:41am Last edited: 29 July 2010 1:48am
We think we've found a bug in SWFUpload/FileDataObjectManager. It's caused when a user without full admin rights tries to upload a file in "Files & Images" through an SWFUploadField.
SS 2.4.0 / 2.4.1
Latest DOM and SWFUpload modules
User with access to CMSMain, AssetAdmin, Reports and Comments. No full admin rights.
When selecting a file in the SWFUpload field and pressing "Upload", the request freezes on processing. With the use of the SWFUpload debug mode and some var_dump()'ing we've located that the permission check in FileDataObjectManager.php line 587 checks for the wrong permission. The checked for permission is
when it should be
We've tried and tested this and it works normally now without errors.
Users with full admin rights automatically pass the Permission::check() function because they've got access to all parts of the CMS and the function automatically adds the "ADMIN" role to check for.
29 July 2010 at 2:11am
Yup, that was fixed in the last rev. Thanks.
|Go to Top||Next >|