Call to a member function setNode() on null

[michielbdejong]

In file '/var/www/html/lib/private/Share20/Manager.php' line 822.

This is because I inverted create and createInternal.

The flow is:

• files_sharing ShareAPIController calls our ShareAPIHelper to create $oldShare
• ShareAPIController calls the built-in ShareManager, which calls our SSP to create $newShare
• data from $oldShare is merged into $newShare in https://github.com/nextcloud/server/blob/v25.0.1/lib/private/Share20/Manager.php#L821

Question is: should our SAH or our SSP make the call to our RHC and thus to Reva?

More detailed:

• NC GUI
• file_sharing app ShareAPIController
• our ShareAPIHelper
  • Reva
    • addSentShare
    • newShare
    • createInternal
    • SSP create
    • createScienceMeshShare
    • addSentShareToDB
      • This is where the share gets created!
  • Reva
• empty response from /ocm/send
• ShareAPIController is done calling our ShareAPIHelper
• now the shareManager gets involved
• lib/private/Share20/Manager
• Manager calls SSP::create but this gets suppressed and null is returned
• Manager tries to set the data from the first share into the second one, but fails because the second one is null.

[michielbdejong]

One thing is certain: SSP create should return the share.

[michielbdejong]

The share should have a full id and a share time. Fixed in nc-sciencemesh dev branch now.

[michielbdejong]

The problem is, when I move this code from SSP create to SSP createInternal (where it should be because there we can fill in the true id), then the error is back. So should we maybe make the call to RHC from SSP create, then?

[michielbdejong]

Tracing again:...

• it starts at files_sharing ShareAPIController line 486, createShare
• straight away, ShareManager line 1780 NewShare is called, setting the rootFolder and the userManager
• some inputs are checked (permissions, path, user permissions on the resource)
• the node is set on the share
• the node is locked
• some more things related to permissions
• now createShare is called on the helper, but I'm not sure whether we actually need to do anything here?
• our helper calls SAH-createShare but I'm not sure whether this is smart because the helper cannot return any data
• shareType and sharedBy are set
• now all the preparation is done, and control is passed from the ShareAPIController to the shareManager
• canShare, generalCreateChecks, pathCreateChecks
• if the storage is external, the owner is set to the mounter. If not, the owner is set to the file owner, or to the sharer
• the target is set
• a preShare event is triggered
• now control is passed to the provider
• back in the ShareManager, a postShare event is triggered
• if configured, the ShareManager sends out an email (but only if the share type is local user-to-user)
• back in the ShareAPIController, the output is formatted

[michielbdejong]

OK, moved the call to reva from the helper to the provider, great progress! Now that the helper almost does nothing we could also maybe avoid having to register it (only register the provider, not the helper)

Anyway, next step: pass the ID through reva.

[michielbdejong]

OK! fixed on the NC side, now the reva side...

[michielbdejong]

Fixed in the dev branch of nc-sciencemesh and the efss-backend-fixes branch of reva