How to get rid of Delete button under Images section

[tomas.voboril]

Hello all,

what would be the best way to get rid of Delete button under Images section?

It happens too often that people want to delete some image (including files) but they do so via this delete button, which leaves the raw image untouched. What would be the best approach? Is there a way to delete this section or have it hidden so guys have to go here to delete the specific image.

Thanks in advance

[Tom Elliott]

@tomas-voboril There’s a plugin called access control that I think you’re effectively looking for?

[tomas.voboril]

Hello @Tom-Elliott,

yes I’m aware of that, this is the current settings we have. Could you please tell me which of those is related to my problem? I’ve already tried to get rid of “SUB_MENULINK-deletemulti” and “SUB_MENULINK-multicast” but the button was still visible.

Thank you,
Tomas

[Tom Elliott]

@tomas-voboril The button would still be visible, but I am fairly sure it would not work.

[tomas.voboril]

Hello @Tom-Elliott,

I’ve tried your suggestion but nothing has changed. Image was deleted but files were still left in storage

[Tom Elliott]

@tomas-voboril So looking at the base code it seems this plugin is translating SUB_MENULINK to SUB_MENULINK_DATA (this is fine, just trying to break it down)

It then uses these rules to effectively prevent a role from accessing these things, or so it seems.

By removing the entry as you have here, it seems, to me, that you’ve allowed deleting the thing.

If the user was part of the role that was supposed to have this removed, then i suppose I need more details as and where possible.

Please remember, this is a plugin. While we have included it into the main FOG project code, this is a custom thing and not guaranteed to work from the outset due to changes in the core code.

I will see if and when I can work on testing out what the problem you’re seeing actually is, but if you have any more details that can help us narrow down exactly what we can do to replicate and what’s not working about it, that will help.

[Tom Elliott]

@tomas-voboril said in How to get rid of Delete button under Images section:

Hello @Tom-Elliott,

yes I’m aware of that, this is the current settings we have. Could you please tell me which of those is related to my problem? I’ve already tried to get rid of “SUB_MENULINK-deletemulti” and “SUB_MENULINK-multicast” but the button was still visible.

Thank you,
Tomas

Where did this ‘deletemulti’ come from?

WHile I know there’s a great amount of need to granularize FOG for access controls, this is just not something we’ve had a large enough development effort of.

I understand wanting this to work how you want it, but just adding things without knowledge of how to best approach isn’t going to work.

I ask this because I do not see a hook designed specificall for -deletemulti
now that’s not to say we couldn’t add it but access controls for “menulink” are specifically designed to remove access to the links that give you things.

So if you wanted to hide the list option for the images (where deletemulti exists) you can do that, but you cannot remove individual segments of the page. This, again, does not mean it couldn’t be added but it’s an effort to add new features like this to be as granular as it seems you’d like to be.

If you don’t want the access to delete multi, for now I’d suggest setting the users to not even see the list link.

You can configure a new role to the effect of:
SUB_MENULINK-hidelist-deletespecific list menu image
As the configuration so it’s specific only to image list item.

Of course if you just don’t want the user to delete anything, you already have an option called
SUB_MENULINK-list

Now, this doesn’t get rid of the edit pages ability to delete.

I’m not sure we’ve had such a request to remove individual page tags, but please remember FOG was never really designed to be access-control specific.

It was designed to be a quick method to create and deploy images to vast machines. Not that it is an excuse but it was never built to be a user controlling aspect, though we do understand that it should be a bit.

As we have worked on making FOG far more secure, the user control just hasn’t been a big part of the list.

I will see if I can work to make all the page elements hooked so that the Access Control plugin has more to glob onto, but then we come into an area of what to name it and how to get Access Control to dynamically see all these things (as it would not be able to operate in the fashion it currently is programmed as).

Not saying it couldn’t be done, just it’s very time consuming and the plugin has to be able to manage itself as well, yay more fun!

[tomas.voboril]

@Tom-Elliott thank you for your time and effort. I fully understand it would take some time to develop those features. Just one last question regarding of what you mentioned in your previous comment
"You can configure a new role to the effect of:
SUB_MENULINK-hidelist-deletespecific list menu image
As the configuration so it’s specific only to image list item.

Of course if you just don’t want the user to delete anything, you already have an option called
SUB_MENULINK-list"

So I should have it like this:

or like this:

Is that correct? I’m a bit green when it comes to those rules.

Thank you

[Tom Elliott]

@tomas-voboril The hidelist-delete specific woudl not be the value, the value should be

Rulename: SUB_MENULINK-hidelist-deletespecific
Value: list
Parent: menu
Node: image

While the SUB_MENULINK-list could be indicated specifically for images, yes, it really shouldn’t be (though you can just re-add a similar one)

That one is specific to all pages’ ability to list items. At least that was the intent behind it I believe.

[tomas.voboril]

@Tom-Elliott thanks for everything. Guess we can close this topic (I’m not really sure if I can do it myself)