Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TVs added to resource group are still editable #7445

Closed
onepack opened this issue Mar 22, 2012 · 10 comments
Closed

TVs added to resource group are still editable #7445

onepack opened this issue Mar 22, 2012 · 10 comments
Labels
area-security bug The issue in the code or project, which should be addressed.

Comments

@onepack
Copy link

onepack commented Mar 22, 2012

onepack created Redmine issue ID 7445

I added some TVs to a resource group so they can only be accessed/ edited by users with access to this resource group.
I now log in with the user account without this resource access and can still see these TVs and edit them as well.

So there is no way to hide some "critical" TVs form some users.

@MarkH
Copy link

MarkH commented Mar 22, 2012

markh submitted:

Sorry, you added a TV to a resource group? That's not the way to go!

Try adding it to a category and using element category ACLs instead.

@onepack
Copy link
Author

onepack commented Mar 22, 2012

onepack submitted:

Hi mark!

Nice to see a response from you ;-) I hope you have a good time working for the MODx team!

About the above. I was confused here as well because I used to do this with ACL's.
But there it was in the TV settings: Resource Group - with the following description in MODx:

h3. Select the Resource Groups that this Template Variable belongs to. Only users with access to the Groups selected will be able to modify this TV. If no Groups are selected, all users with access to the Manager will be able to modify the TV.

Is this confusing or what?
Maybe delete this option in TVs or MODx can explain how to use this properly.

Misschien ben je me nu al zat hehe, Maybe you are fed up with me already.

Greetings,

OnePack

@MarkH
Copy link

MarkH commented Mar 22, 2012

markh submitted:

Learn something new every day o.O I had no idea you could link it to resource groups, I always did it with categories, but apparently this is a legacy feature that should work.

@splittingred
Copy link

splittingred submitted:

I can't replicate this; I did the following:

  • Created a new TV named "tv7445"
  • Assigned it to my default template
  • Restricted it to user group "ug7445", of which i was not a member
  • Flushed permissions
  • Both edited and created a Resource, neither of which showed tv7445 as editable

@onepack
Copy link
Author

onepack commented Mar 23, 2012

onepack submitted:

Hi Shaun, thank you for your time!
I reproduced it on two different projects with two different hosting companies.

Somehow the tvs stay accessible for users that are in a usergroup that don't have rights to view these Resource Group items

See the Images to demonstrate.

@onepack
Copy link
Author

onepack commented Mar 23, 2012

onepack submitted:

Shaun, when you want I can provide you with the login credentials of the latest project so you can test it. info[at]onepack.nl

@onepack
Copy link
Author

onepack commented Mar 23, 2012

onepack submitted:

When I create a new TV the Resource Groups checkbox field in the Access Permissions is not rendered so I need to do that manually.
After I select it and Save the TV the checkbox is empty again on a second load of the TV.
When I check the access permission checkbox TV at the second time that I load the TV it will stay checked like it should.

I also Noticed that when I create a new TV the following error appears in the error-report.

[2012-03-22 23:21:59](ERROR @ /connectors/element/tv.php) modTemplateVarTemplate: Attempt to set NOT NULL field rank to NULL

@splittingred
Copy link

splittingred submitted:

Yes, login info would be nice. shaun@modx.com

@splittingred
Copy link

splittingred submitted:

Thanks for the testing data. Can you test this fix:

e7bd6f2

This seemed to fix the issue - which I confirmed - when I applied this commit.

@onepack
Copy link
Author

onepack commented Mar 28, 2012

onepack submitted:

I confirm that the applied fix solved the issue.

enigmatic-user pushed a commit to enigmatic-user/revolution that referenced this issue Feb 13, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-security bug The issue in the code or project, which should be addressed.
Projects
None yet
Development

No branches or pull requests

3 participants