Resolved Backend download file from custom module?

Hello,

I know there is an option to add a menu item in the frontend (with frontend download enabled and a Secret key ins the URL. So we can have a user download it from the frontend. But I also would like the downloads to be possible from the backend in a custom module with a simple download link.

You can use Joomla custom HTML module and insert Frontend link so user can run import/export from custom module. It can be a administrator module but with frontend URL. Let me know if that works.

Thanks Tharuna, this works for me.

Some pointers for future reference:

Info about creating a (manual) frontend link:
https://rolandd.com/documentation/ro-csvi/setting-up-a-front-end-template

You need to enable the frontend option and setup a key and add that to the URL.

Also when adding the links to the module in the backend, when you use the JCE editor) the first part (domain) is removed from the URL on saving. I solved this bij adding a backslash (at the beginning) of the modified URL. This backslash is not removed bij the JCE editor and will point you to the frontend. Otherwise the link tries to open in the backend.

Downside of this solution: You have to expose the data to the frontend.It would be great to be able to trigger the download in the backend as well. So we don't need the frontend option enabled. But when you want only access to the downloads performed by these links (and no access tot the extension) you still might need a way to allow only downloads.

Having a RO CSVI dedicated module might be a nice addition to the extension package.

Hi,

The main problem I see with your request to start a download is to do so without access to RO CSVI. Somehow users are going to need access to RO CSVI otherwise the component will not be executed.

Also when adding the links to the module in the backend, when you use the JCE editor) the first part (domain) is removed from the URL on saving.

Yes, always annoying with these "smart" editors. Switching to CodeMirror for example would work to or toggle to code mode.

You have to expose the data to the frontend.

The whole notion of backend and frontend is something that is not some magic but just a different URL. Whether something is exposed primarily depends on how the ACL is configured. You can set access to the download links only to a certain group and make the people who are allow to run the downloads part of this group. So I do not see the issue of exposing data to the front-end.

Thanks for your info RolandD. I will have a look at the ACL settings for the download links.But will that work when the backend en frontend sessions are not shared? When a backend user is logged in and the sessions are not sharded and the download is initiated from the frontend, the user is not logged in to the frontend... So when we set a usergroup for the frontend downloads, we could put the backend user in it, but since he/she is not logged in to the frontend the download won't work? This would mean I either need to set the download link ACL to public or enable session sharing?

Hello,

But will that work when the backend en frontend sessions are not shared?

Yes and no, that depends if the user is logged-in on the front-end. If the user is not logged-in on the front-end this will not work if the menu item is linked to a usergroup other than Public and shared sessions is not enabled.

This would mean I either need to set the download link ACL to public or enable session sharing?

That is correct.

Let me know if you have any further questions.

In my specific usecase we don't have frontend usergroups. We just need a download from the backend. So then we do need to use the 'public' usergroup. I know there is a key in the URL, but still feels - as I stated earlier - like exposing data to the frontend...

So having a way to download data from a backend module, without access to the component in the backend, with a link link the frontend download link, for us would be a nice feature. But I can understand this might be kind of an unique scenario and you can't accommodate this.

I think maybe adding access to the backend component might be the best solution for us now. I just prefer not to have to many users to have access to this powerful component...

Hello,

Indeed you do not want to set the menu item to Public unless the export contains data that is visible to the Public; otherwise you are exposing it to the front-end indeed. That is why you would enable the shared session so you can set the menu item to a usergroup and the user would not have to login again. Although I am not sure how much of a nuisance that is. Either they login on the frontend and click a download link there or they login to the backend and click a download link there. There is not much of a difference.

So having a way to download data from a backend module, without access to the component in the backend

The module itself would not be doing the export, that code is part of the component. You are always going to need access to the RO CSVI component.

I think maybe adding access to the backend component might be the best solution for us now.

If you only want access through the backend then yes these users must have access to the component. The only other option would be to build an ACL around the individual parts of RO CSVI, that is somewhat of an overkill and in this case you are the first one to ask for such a feature.

Why does it have to be in the backend? Can't these users login to the front-end and have a menu for themselves with the download links?

Hi RolandD, thanks for sticking with this ;-)

I have decided not to use the frontend links in the module anymore. The frontend access and shared sessions approach won't work for me for several reasons.

I disabled the frontend download option and removed my custom backend module with the links and now gave access to the RO CSVI extension to the usergroup (backend users). I gave them access only and no other rights. Now these user can go to the templates and click the 'run' button to download the data.

The only thing I would like to do now is to restrict access to all other RO CSVI submenu items, other then 'Templates'. Because now these user could also perform maintenance task for example. Or Analyze files. Or the actions in the 'about' menu. It would be nice it we could just give this usergroup access to the templates only (to be able to run them).

What do you think?

Hi,

I actually rather enjoy this discussion.

The frontend access and shared sessions approach won't work for me for several reasons.

That is perfectly fine of course.

It would be nice it we could just give this usergroup access to the templates only (to be able to run them).

Be careful what you ask for Just joking but this did give me another idea and that is a solution from the Joomla core. You can create your custom backend menus using Joomla core, so you only show the items you want a user access to, exactly the way I have done with our demo sites.

This does not prevent access to them but would require users to mess with the URLs in the browser, if they go to these lengths, are they worthy of backend access at all

Besides that I will have a look and see how easy/hard it is to implement some more ACL options to access the different views.

Let me know what you think of the idea of custom menus for your Backend Users group.

I have tried creating custom backend menu's for user a couple of times and it was very disappointing. So I am hesitant to use that. I might try again some time in the future...

It think being able to somehow grant access rights to any Joomla menu item would be a nice feature. Not sure how though ;-)

We did have some issues where components did add access rights to some parts of the component, but the menu item still shows up. When you don.t have right to that menu it just said 'not allowed'. I created a feature request for that on the Joomla CMS GitHub repository. But I think that component developer can easily add the hiding of menu items when there is no access themselves. (https://github.com/joomla/joomla-cms/issues/40700) A developer that works for me did this and also AcyMailing did it (with our code suggestions).

But first there needs to be some access rights management for parts of the component.

Anyway, for now I found a different solution:
1) I created a plugin that adds classes to the backend HTML body tag bases on the usergroups the logged in user is in. Classes like this: 'usergroup-1 usergoup-2').
2) I used backend template CCS to hide all submenu items of RO CSVI except the first one and also not for the SU group.

It works ;-) It's not actual right management, but hiding the menu items is good enough for me. I just want to keep it clean an simple for the backend users.

If you ever decide to add some rights management to the different parts of RO CSVI (and hide the menu items with no access right) that would be great. I would be happy to help you out with some testing.

Screenshot:
https://drive.google.com/file/d/1N10mxO48ifoAQ3JQkNoSgP2Of_v_vd9h/view?usp=drivesdk