Here are some initial tests. I really wanted to make them pretty general, but overall was not too successful in them. Ideally the test would test combinations of different permissions, different node/entity types, custom fields, multiple roles, etc. Instead this tests uses the built-in page node type with the body field, but then uses two roles with gradually changing different sets of permissions.
It always checks the default behavior and then enabled certain features and sets their permissions and checks differing behavior for the two roles. I've included coverage for the core create, view and edit operations (view own and edit own are not included).
Unfortunately the test does have some interesting failures which I've spent quite some time debugging, but since I'm still puzzled, help would be appreciated.
1. All user_access() checks where I check for positive permissions fail. (But then when I actually test the effect of the positive permissions, those go through). This is probably some caching at play, but drupal_static_reset('user_access') was not enough to help. 3 failures involved
2. In the "edit" section, there are 2 test fails I cannot understand. They are both about the body edit field not being accessible when it should be. Ie. I have create and view permissions exposed for the body field but no edit permission. Even though, it seems like the body field does not show up on editing. This is either a bug in the module or a wrong assumption in my test. Independent verification would be great.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | field-permissions-tests-followup-1298966-4.patch | 7.36 KB | David_Rothstein |
| #2 | field_permissions_tests_2.patch | 12.31 KB | gábor hojtsy |
| field_permissions_tests.patch | 9.51 KB | gábor hojtsy |
Comments
Comment #1
David_Rothstein commentedI think it's extremely confusing behavior of the module; whether it's a bug or not I'm not sure. The way the module currently works, view and create/edit are treated as separate "groups" of operations. As soon as you enable any permission in each group, you are saying you want to control access to that kind of operation, and since access is denied by default, that explains what you saw.
This is confusing even for related permissions (e.g. "view" + "view own"), but at least kind of makes sense there - if I click a checkbox saying that 'only administrators should be able to view field X" it would be bad to leave a backdoor where the node author can automatically view it too without the UI ever informing me that that's the case. However, the fact that "create" is lumped in with "edit" for these checks seems like a potential bug.
Either way, we're planning to get rid of this concept of exposed/unexposed permissions at #1279712: Revamp the Field Permissions user interface to make it more intuitive (after that, for an individual field, either all 5 permissions will be exposed or none of them will). This will make things a lot easier to understand, and it will also get rid of this problem in the tests, so we probably don't need to worry about it here now.
Comment #2
gábor hojtsyAll right, here is updated tests, assuming the UI revamp patch is comitted. It still fails 8 times, and I still think it should not fail either time. Here is the breakdown:
1. Line 131 fails. It checks that if we choose to make the field private, admins can access the field on view. They can't.
2. Seven instances of user_access('name of permission exposed by field permissions') where I check the user has that permission all fail. However, when I check them in action, they all work. So still not sure what is going on there.
Another set of eyes on why this would happen would be great.
Comment #3
robloachI'm going to commit this as it's a very good starting point for tests. Not entirely sure why 131 fails. My user testing is fine, but the tests itself fail. We'll have to look into that.
Pushing to critical so it gets in before alpha2. Thanks a lot, Gabor! Love having tests. http://drupalcode.org/project/field_permissions.git/commit/0b60620
Comment #4
David_Rothstein commentedLots of SimpleTest weirdness going on here. The attached patch should make the tests pass.
If you run the tests you'll still get two exceptions due to "Undefined index: entity keys" PHP notices, though, but that's the result of a core bug (#1301522: field_ui_default_value_widget() does not pass along the entity type when it creates the default value form).
Comment #5
robloachYAY PASSING TESTS! Thank you so much for hunting down the static caching issue. Was having troubles finding this yesterday. Committed!!! And now we have passing tests :-) . http://drupalcode.org/project/field_permissions.git/commit/3b5cf73