Hey UncleCheese, I asked you about this a few weeks ago and I'm still having trouble with it.

In FileDataObjectManager.php line 623:

$file->OwnerID = Member::currentUserID();

After looking at Member::currentUserID I found that the session isn't working, $_SESSION is returning an empty array. But if I access the controller director $_SESSION has its normal data in it.

I'm not familiar with how swfupload works, but I'm suspecting that perhaps the flash application that uploads the file has its own session (or no session?).

What do you think?

It's a known issue with SWFUpload that whatever session you happen to have active won't follow along unless you send in the session id as a variable and set the session yourself manually. I have no idea how messy this would be to setup in SilverStripe if it's possible at all since you have to do this before SilverStripe starts the session.

Is there a reason for why you have to do this in the method that handles the swfupload though? Basically you have two chances to hit that file, once when it's actually uploaded by swfupload and you don't have session access and a second time when the form saves through $data['uploaded_files'] if you're using the field in a regular form. Right now I'm assuming you're using it outside of the CMS, inside the CMS I'm not sure when the best time is, onBeforeWrite() perhaps? Maybe you can grab it through $_REQUEST['uploaded_files'] then.

Let me know if any of that helps. I use the method with $data['uploaded_files'] when I use SWFUploadField in my regular forms outside the CMS and it works great for me, never tried it in the CMS.

The module is installed in dataobject_manager, however, the DOM CSS code isn't being included in the source file. I tried including it in the init() member of the class Expert extends DataObjectDecorator, but this was ignored too.

Is there a way to include additional CSS in the Security tab?

Hi Smurkas,

Thanks, I didn't know it was a known issue.

I'm not doing anything out of the ordinary here in regards to DataObjectManager and I'm guessing that this has perhaps always been a bug in DataObjectManager.

I've tried doing it onBeforeWrite(), but as it is still swfupload that has created the request, onBeforeWrite also suffers from the lack of session.

I can't think of any way to get DataObjectManager to properly save the OwnerID other than to pass the session variable into swfupload like you've said, but I'm not sure how to do that.

UncleCheese, do you agree that this is a bug in DOM?

Cheers

If swfupload can upload files without a session, does that mean it's not authenticated in DataObjectManager?

I'm not sure how it's done in the CMS but SWFUploadField has it's own controller called SWFUploadControls which handles the actual file upload. When this method runs there isn't a session in the request or rather a new one because of the Flash issue. I understood it as it's during this request cycle that you're trying to act.

I was thinking that you should act after this has happened. I'm guessing that the file is attached to some other object or page and when the related object is saved then that's when you act. I'm hoping here (although not sure if this is how it actually works) that you'll be able to access the request data to get at $_REQUEST['uploaded_files'] to find out which files that actually were added and then do something with them.

If this is what you're doing then you do indeed have a real issue on your hands which might be really really hard to solve. I'll do a test case and post back here with my results.

Ok I've had a look at it in the CMS (debugging in the CMS is such a chore) and it appears that you are correct. When SWFUpload is used in the CMS and you press upload then it actually saves the related object as well during the same request cycle. When I've used SWFUpload in the frontend it's not how it works, SWFUpload saves first and reports back the id:s of the files and then when the user clicks save the related object is saved (or at least that's how I do it). This means I get two separate request cycles and don't run into this issue.

This doesn't help you of course and I'm not sure if or how your problem can be solved. If you send along the session id as a custom variable in SWFUpload, maybe you can store the current session id, kill the session, start the session with the session id from the custom SWFUpload variable, do your stuff, kill the session again and then restart the session again with the original id for that request cycle just in case it contains anything important. Use session_write_close() to stop and save the session instead of destroying it.

Sortable DataObjects are sortable even without create, edit and delete rights within ManyManyDOM.
Also when manually setting the record to read-only ($MMDOM->isReadOnly = true), the check-boxes behind each record get disabled but you're still able to re-order the DataObjects

SS: 2.4.0
DOM: Trunk revision 400