Remove add and delete buttons from "list all XYZ" pages in 1.6

[tailz303]

We are a unique use case for fog. We have 50 ish schools across our county that all have fiber to our DC. our HS MS and Intermediate schools have 10 gig and the elementaries only have 1gig. each elementary school has a fog node that is a storage node to our master elementary node in the data center. Each secondary "cone site" consists of a High school, middle school, and Intermediate school. in each cone site there's a master node at the hs and a storage node at the other 2 schools. each one of our cone sites has a dedicated tech who manages all fog stuff for their cone site. We want to centralize fog to have our DB, master images, and massive number of hosts backed up in the datacenter and also make updating our default images easier.

This is where we are exploring 1.6. we have decided to use this version because it supports pagination, and is a lot cleaner looking. We are planning on having the master master node on the proxmox cluster and have normal master storage nodes at each high school and standard storage nodes at the MS and Intermediate schools. the elementaries will all have standard storage nodes.

We use LDAP mainly for non Google services, so we are looking at using the 1.6 LDAP module, locations, site, and access control plugins. we are running into a swath of peculiar issues though.

The first is found when using the access control plugin to remove the "create", "import", and "export" entries from the menus leaving only the "list all" option, users are able to use the add and delete buttons there to create and delete these items anyways completely invalidating the point of access control blocking access to the create menu item.

we are trying to organize our cone sites into sites within the "site" plugin and there doesn't seem to be an intuitive way to implement it correctly. we want to limit our cone site techs to only be able to modify edit add or remove hosts images etc in their site but it first doesnt restrict them at all, and there doesn't seem to be a way to ensure that the user who creates the host won't lose the host to the void if permissions aren't set right when it's created.

It would be nice if there were user groups and if control was a little more granular. Currently access control kinda just hides the link, but something like proxmox completely removes the ability to do anything with perms that aren't given to the user. it would be nice to be able to have 8 different sites with the ability to assign users to those sites and them have no way to mess with each others stuff.

We use fog pretty extensively at our school district, and love the project. This rant is more to hopefully give some insight on how we use our setup to help shape the beta. If I think of anything else I'll put it below, and if something in my rant doesn't make sense please let me know.

Thanks,
Cody

[mastacontrola]

I had to create a hook path for it, but this should be working better in working-1.6 though still trying to work out how to incorporate the actionbox removal. Access Control plugin is a simplistic plugin at this point. It will need a TON of refinement to make it work as FOG was never really built with access controls from the get go.

To incorporate properly we'd basically need to restart fog from the ground up and unfortunately there's just not enough of a team to do so. So with a little (really a ton of course) work we can make the access control plugin work to incorporate this, but it will be a slow process.

To remove the add/delete though, please update the lastest working-1.6 then go to access control rules and add:

Basically the Rule Parent, in this case, doesn't matter, but is where the add/deletes are consistently added. Note this is not going to remove editable features as those buttons fall into different areas.

[tailz303]

Yeah that does make sense. Honestly if the access control plugin were to become the place where all access control is done that would be awesome. I know for some its nice not having to worry about perms at all so being able to remove that and have everybody be an admin is nice. It is hard on the team though because 1.6 is a complete redesign which makes squashing these random bugs even harder. Would it be possible to feature request pagination in 1.5.x potentially? That is the only real reason we went to 1.6, because we have thousands of hosts and it overwhelms everything without pagination.

All that said, I pulled the latest and did something similar to what you had in your screen shot and theres a very high chance I did it wrong, but it didn't seem to remove the ability for our locked down test user to add groups or hosts for instance:

then this is what the test user sees:

But that is less of a deal because we can just talk to our techs and tell them not to make things they aren't supposed to be making etc.

[mastacontrola]

The Rule type needs to be exactly ACTIONBOX

The Rule Type = the "event" we're triggering against. IN this case the add/delete buttons are presented through the ACTIONBOX event.

The Parent would be sub items if there were, in our case, there is 0 sub's but the Parent is a required field, so any value here is possible.

The value is the "key" that we're working against.

The ACTIONBOX event only has a value of 'actionbox' which is the thing we're removing.

Hope that helps explain things a little bit.

node would be delved specifically to individual pages if you wanted it. Say you only wanted to remove add/delete on hosts, you would host the Node value to host, or image, or whatever. If you want it on all, you would set node.

In the case of actionbox I just did a quick fix. So setting node won't really change how it operations at this point in time, but you can see how granular you could become.

[tailz303]

Well I tried that but I just realized that upon updating the server, all rules that restricted our locked down user no longer work, including the actionbox one. I don't think I changed anything, the user and every rule is assigned to a role and no change, the test1 user has everything the admin does.
seen here:

a page of our previously working rules (removing the _nameDescription after "MENULINK" does not fix them):

[mastacontrola]

So Rules are assocated to the overarching access control.

The code changes I've been making have not changed the overall functionality.

So AccessControl would need the specific Rules and Users to be associated.

It's relatively simple overall I think.

Basically just did a "Role" (AccessControl) I called Read Only.

I created the Rule ACTIoNBOX-actionbox with:

I then created a readonly user for testing.

I then associated the Read Only role with all rules except the selected items here:

Then I associated my readonly user to this Role as well.

Then I logged out and logged back in with my readonly user.

Things are working correctly.

Also, I just pushed another change to allow the node granularity to operate too.

[tailz303]

Edit: I will update to the latest branch to test that change you pushed

Here's one of our rules, we have this to stop the test user from managing users.

This morning the test user couldn't see the users drop-down at all but when I verify that the user is assigned to a role with this rule this is what the test user sees.

That's why I'm confused because none of our previous working rules are working anymore, it might have been an unrelated change from this or something that affected it but the only change is that I updated. Is there something else I need to do that im missing? I even re-created the role and reassigned the rules back in case the sql server had remnants of old rules

[mastacontrola]

This is me testing currently and so I'm not sure what's happening.

[mastacontrola]

It's working properly for me and the things I want hidden are indeed hidden.

This may be a bit extreme, wondering if removing the access contorl plugin and reinstalling it might work better for you?

[tailz303]

I would say that fixed the issue. It nuked all of the rules we created which we created because the default ones didn't work initially hence why we had to make them all but maybe the script flipped because the default rules now seem to work. That also fixed the actionbox issue not working so that is good. Who knows what caused it but everything seems fine now so thank you!