The usual method of creating the render of a block from program inserted data, as you would do for showing a block in a theme (lots of posts in the forums about that), will not work because an FEFU then has to go back through a tool that re-creates the block controller and that needs a genuine block ID, controller and data from the database.

Whatever your solution, it will have to create actual blocks on actual pages.

In the process, it will need to create a file set, get its fsID and use it as you create the block. The other thing you will need to change between each block created is the access_uID, which is the uID of the user who has front end access.

When creating the block, you will need to set up the $_POST data array with data as per the db.xml for FEFU. For all the other block data, the easy solution is to create a block with the appropriate parameters, save it, then read it's parameters back as a 'template' for each user and fileset specific block.

So (pseudocode):


You will need to take care over data that does not map 1:1, like options and accepted_types (which are imploded/exploded).

In the process, you may find it useful to sub-class/inherit the FEFU block controller rather than using it directly. That will enable you to get inside and manipulate data more closely than through the public interfaces.

As I mentioned in my response for FEFM, for the coming Concrete 5.6 release I have a change proposed for the core BlockController class that will enable addons like FEFM and FEFU to be easily adapted based on page or user attributes, so there could be other mechanisms available in the future.

This change proposed for C5.6 inserts a C5 event at the point a block's data is loaded. You can then write an event handler that modifies the data that actually gets loaded.

So, for example, your problem would be solved by having a stack of FEFU (and other blocks) copied across all these pages. Then writing an event handler to tweak the access_uID and fsID of the FEFU block as it loads depending on what the page cID and owner uID are.

Overall a much simpler solution, but it depends on my change making it in to C5.6.

On github, you can read the pull request
https://github.com/concrete5/concrete5/pull/598...
(And also see that I am not that good at driving GIT)If you have a GIT user id, you can add a +1 comment for that change.

Thanks, that was enlightening! A follow up question:

As the last resort I was planning to modify DB records of newly created pages with FEFU blocks preset in Page Types. If all I need is to assign a specific fileset and a user group (not a single user) who has access to uploading, in my mind that only two changes that have to be done to the database, possibly in one SQL statement. In my script I already have fsID and gID available to me.

If so, what would I need to change?

Again, thanks for all the help!

Its hacky, but could be the easiest solution.

The block table is btJlFrontEndUploader and the fields are as named above (and in the db.xml for FEFU). Just have a look with phpMyAdmin.

Be aware that bID changes with each save, so your sql needs to select based on the current bID and not a previous bID.

Creating filesets would be best done through the C5 api rather than hacking the database and its easy enough to get the fsID through the api. Same for user IDs.

v2.0 now integrates with Magic Data, so you can use a magic data expression to decide which fileset(s) an uploaded file is added to.

For example, each user has a favoured fileset stored in a user attribute. FEFU could process a magic data expression to retrieve that user attribute and make the current upload target the fileset specified by the user attribute.