Testing that a global request is available for subscribers of statusupdate creation.

[simonedeponti]

This is quite similar to the portal problem, only relative to the global zope request.

This is what you usually would get using zope.globalrequest.getRequest() or via the REQUEST attribute that is acquired by persistent objects.

[simonedeponti]

Okay, this pull request needs further work.

Things we need to support in microblog (atleast for docconv to work properly, whatever async framework we base it on):

• Have a physical path it can then be traversed to (this is used to serialize/deserialize the object in the async worker)
• Set up a global request (also accessible via zope.globalrequest)
• Since docconv also handles HTML to PDF, we need, when we create the fake request in the autoflush thread, to bring over all the information on virtual hosts and rewrites (else the converted PDFs don't see any images)

@reinhardt can you confirm that with this set of features docconv should be able to work with some changes here and there?

@gyst do you think there would be problems in supporting atleast getPhysicalPath on StatusUpdate objects? (here a rather simplistic implementation: https://github.com/collective/collective.simplemanagement/blob/master/src/collective/simplemanagement/booking/content.py#L99)

[simonedeponti]

@gyst furthermore, I am going to disable the insertion of files into the status updates by changing the JSON file that is read by the import step, as I don't think we are going to solve this issue soon. This way we can have a content creation step that work for atleast basic stream functionality.

[gyst]

@simonedeponti I think a getPhysicalPath implementation along the lines of the example you gave is a good idea. However we should avoid having the actual StatusContainer tool in the path. The example justs injects a string instead.

Note that this is very similar to the view traversal we already use like /@@conversation/statusid https://github.com/cosent/plonesocial.activitystream/blob/master/plonesocial/activitystream/browser/statusconversation.py#L38 and we have a similar view traverser in plonesocial.network for the likes.

[reinhardt]

Does it have to be a traversal? Couldn't we also implement a special case for StatusUpdates and get them from the Microblog Tool using the status id?

Regarding HTML to PDF, I don't think this is relevant for attachments to StatusUpdates. The feature was intended as a way to "download" Document objects (as a PDF). Attaching HTML to a StatusUpdate sounds like a rare case. If we don't support this then I don't think we need the virtual hosting info from the request in this case.

With that in mind I don't see any big trouble on the docconv side.