Closed (fixed)
Project:
Protected Node
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
30 May 2014 at 13:59 UTC
Updated:
28 Jul 2015 at 17:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
grimreaperComment #2
grimreaperComment #3
grimreaperComment #4
grimreaperWith global password, the view of the node fail. It is "normal", it is related to this issue https://drupal.org/node/2266507
I lost a lot of time in these tests because at the beginning I used :
To create node. But the protected node module stored nothing and I realised that when I wrote the tests for per node password. I was fooled because the assertText was on the nodes' title and its were shown even on the password form even when it fails.
So now I use the node's body.
I also lost a lot of time before founding that :
To set the password method was not good. No need of an array.
Now It should be good for those basic tests.
I wait your feedbacks.
Thanks for the review.
Comment #5
izus commentedok
a quick look to the patch and here are my thoughts :
let's do it step by step :
let's focus first on :
password per node :
Creation (storage of the password) needs review
View needs review
only that until it got merged, then we go ahead.
i'd like us to work on that patch first as it's the first test we will have.
the users created for a test case should really have the minimum permissions that are needed.
if during test writing we need to fix a bug, let's do that first and even commit the test with the bug issue. tests should keep clean state of the project (well clean may not be the exact word for now, but let it be a target ;))
Comment #6
izus commentedalso it would be more readable to use a single test file for each test category (edit or even each class)
Comment #7
grimreaperFor the tests in each file. I forgot to mention that I also want that, but I don't know the proper way to make that.
Ok, let's focus on password per node. While my first patch is not lost it's ok. :)
I will see that this weekend.
Comment #8
grimreaperThis patch only tests password per node. Creation and view.
The tests are in their own file.
Comment #9
grimreaperI remade the previous patch to respect some coding style standards of POO and comments.
Comment #10
izus commentedhi,
here is a reworked version based on #9
- added a user with only access content permission
- added a test for that user
- handeld all the tests for "by node protection" in one single class
- added extra method for common used code to avoid duplication
- delete unneded global string definition
- made the test nodes load by title instead of by id, as the id may differ in the future.
- Added a test for user with permissions but wrong password
tests pass but simpletest complains about
Undefined property: stdClass::$protected_node_emails Notice protected_node.module 865 _protected_node_save()
i think we should fix this.
so Todos here :
- fix the Notice issue
- Review the patch and if needed complete it
Comment #11
izus commentedfixed the the notice in #10
all green now :)
will just need a review and maybe feed up the patch with extra cases if necessary.
Comment #12
izus commentedtesting if automated tests will be triggered
Comment #13
grimreaperYour version is much clearer. :)
I just had messages on the asserts to locate them easily among the debug messages.
Now I understand better how you wanted the tests to be organized.
About the notice, I already have it in the patch at #2266507-2: Global password does not work properly
If it's ok, I will wait the first test to be merged. Then I will rebase #2266507-2: Global password does not work properly and write the other tests in this issue.
Comment #14
izus commentedi think the $group thing needs a decision before we go far on all the other tests.
https://api.drupal.org/api/drupal/modules!simpletest!drupal_web_test_cas...
actually the $group added in #13 seems more like a short version of $message, but this is not the intention of $group.
i still think that it can be sth that is good to have if we use a defined set of groups needed in this module, but it should be general and not specific to a test. i belive the groups can be related to a feature or one of this module submodules (rules, views) it also can be the feature teste in the file (per_node_protection, global_password_protection,...) or even a mix of all that.
anyway it should really be $global :)
how about this ?
Comment #15
grimreaperHum, no... the $group in #13 is more like the name of the test function, that's how I thought them when I wrote them.
I don't think the $group should be feature specific as a feature is already in (its own file and) its own class. So in the UI of testing, it's easy to separate them.
And as I retest to see the impact in the UI. I just realize that for assertresponse there is no $group... So I add this new patch...
So, ok, If you want something global; global $group = 'Protected node' ?
I think the name of project or the name of the module, therefore the submodules will be hightlighted.
a global variable or a constant ?
Comment #16
izus commentedi'm ok with that :) let's keep it as simple as 'Protected node' :)
Comment #17
grimreaperOk.
Add $this->group = 'Protected node'; in test's setup().
Remove protected $adminuser and protected $normaluser in ProtectedNodeBaseTestCase as they are useless.
Hoping it will be good this time :)
Comment #18
izus commentedoki thanks,
this is merged now
We should update the issue summary and keep going n for other tests
Comment #19
izus commentedback to needs work status for other tests
Comment #21
grimreaperComment #22
grimreaperComment #23
grimreaperDo you prefer a patch (containing tests) per feature or a patch with tests for several features ?
Comment #24
izus commentedhi,
actually the same order as in the issue summary seems good.
let's move to "password per content type" tests or "global password"
Thanks
Comment #25
izus commentedComment #26
grimreaperHi,
Here is a patch that add tests for per content type protection.
Thanks for the review.
Comment #27
grimreaperHello,
I add a test about the email. So this patch contains both protected_node.per_type.test and protected_node.mail.test
But I don't know why protected node does not detect anymore the tests in protected_node.per_type.test.
Comment #28
izus commentedHi,
juste to make it easier to follow, i'll drop the 2 reviews separately, so this one is for the easiest one : emails :)
This one should definitely belong to the parent setup for all tests
$node is not used, so we can delete this extra variable.
Comment #29
izus commentedalso de we really need $this->group as getInfo already defines the group ?
Comment #30
izus commentedand here is the remaining.
i belive we have more code to do for a lot of cases but actually what is really good is that we are building a good and solid base here.
Thanks for contributing !
let's call it page_type_password or page_password or eaven page_content_type_password to be clear that it's specified for page content type !
"sees" or better : "is viewing"
Comment #31
grimreaperHello,
emails
from https://www.drupal.org/node/583030
per type
I attached a patch containing the two tests. As well as two patches with the tests separated.
Thanks for the review.
Comment #35
izus commentedwith local tests, it fails for emails
Comment #36
izus commentedlocally, when i process the email test step by step in the UI, i have an error when i submit the page create form :
Warning: class_implements(): Class DevelMailLog does not exist and could not be loaded in drupal_mail_system() (line 278 of drupal7/includes/mail.inc).
Exception: Class DevelMailLog does not implement interface MailSystemInterface in drupal_mail_system() (line 283 of drupal7/includes/mail.inc).
i don't know yet if it's due to some local hack or if others can reproduce this
Comment #37
izus commentedi think it's due to local configuration
drush vget mail_system
mail_system: array (
'default-system' => 'DevelMailLog',
)
but what is really weird is that simpletest reported back this issue, i thought simpletest creates a new envirement to be dependent from local configuration ! oO
Comment #39
izus commentedit was juste that tests pass now, thanks.
it's merged now, back to active state to continue this effort
Comment #40
izus commentedi wil add this little patch to :
- have good comment style inside methods and functions.
- add the group in the parent setup instead of doing it in each test setup.
- code styling
Comment #41
izus commentedtriggering the tests bot
Comment #43
izus commentedComment #46
grimreaperHi,
Sorry to have forgotten to warn you about the devel problem. I also got it and I was also surprised of that.
Sorry for the coding style problems, I thought my IDE was well configured. It seems not..., maybe I configured for one project and not globally. :(
Updating issue summary.
Comment #47
izus commentedall tests are green locally, nomatter what test bot is saying ;)
Comment #48
grimreaperUpdating issue summary has test for global password feature has been postes here : https://www.drupal.org/node/2266507#comment-9062857
Comment #49
izus commentedComment #50
grimreaperUpdating issue summary.
Comment #51
grimreaperHiding files. Sorry for double post.
Comment #52
grimreaperHello,
I manually test the cardinality tests.
I found that with the core with the upload widget you can use a file in only one place (or I miss something).
Therefore to be able to use a file in several places, I enable file_entity and media modules. Using the media selector widget.
With the default file_entity and media permissions as file_entity add the specific permission "view private files", checked for anonymous user by default.
I test that if a private file is added in an unpublished unprotected node, anonymous user can't access the file with the URL. Ok, normal.
I test that if the same file is added to a publish protected node, anonymous user is then redirected to the password form and if he/she enters the correct password he/she gains access to the file. OK, normal.
I think I am going to write those tests. But I wonder, should I make another separated files for the test as it requires file_entity and media or use the current test file for private files ?
I also wonder if those tests are relevant, as it use contributed modules and the contributed modules on media management can have different approaches.
Waiting your go Izus to write those tests.
Comment #53
izus commentedok so here is how i see it
1) without any additionnal custom module we should handle multiple file field values (actually we are assuming a file field has only one file value in it) this will implie current code change and maybe test also, but it will be a small patch.
2) caring about the file reuse stuff.
here we can add a new file test and enable file_entity in it using the simple test static variable $modules
example of this in d8 (i think it's the same with D7)
here we will implement the wanted tests and should pay attention to the code modification that thios will implie (it should be wrapped in if(module_exists(....
document this feature in readme with the table in the link https://www.drupal.org/node/2179473#comment-8744327
if media does the reusing files differently , we can add another thing fo it, but i belive it's all done the same way : injecting the file object content
media requires file_entity, so i belive it's the same mechanism
:)
Comment #54
grimreaperComment #55
damienmckennaComment #56
grimreaperHere is a patch that add tests on statistics.
Comment #58
izus commentedThanks for the statistics test patch
This is now merged
back to needs work for the other parts to test
Comment #59
izus commentedComment #60
izus commentedComment #61
grimreaperHello,
I attach a patch to add test for the bulk actions. I have started with the "clear sessions" action.
Thanks for the review.
Comment #62
izus commentedReviewed and merged #61
Thanks
Comment #64
damienmckennaI believe this is the correct status? :)
Comment #65
grimreaperHello,
Unfortunately no, there are still tests to implement.
I update the issue summary.
Comment #66
grimreaperAdd test for remove protection.
Comment #67
grimreaperAdd test for restore protection.
Comment #70
grimreaperComment #71
grimreaperFix issue markup.
Comment #72
grimreaperAdd tests for use global password.
Comment #74
grimreaperComment #75
grimreaperAdd test for reset passwords action.
Comment #79
grimreaperAdd test for protect node action.
About the falling test for reset password action. If someone can test it locally, I will be very thankful. I think I will open an issue that will regroup the test falling on the testbot.
Comment #81
grimreaperComment #82
grimreaperAdd test for private file reused across multiple nodes.
Comment #85
grimreaperComment #86
grimreaperLet's debug the two remaining tests that do not pass on the testbot.
Comment #89
grimreaperAnd now both tests pass!!!??? Are you kidding me testbot? lol.
So, could we close the issue?
Comment #90
izus commentedcool,
so https://www.drupal.org/node/2179473#comment-8744327 just needed tests without any code fix ?
great work here :)
Thanks man !
i think we can close it if everything is ok.
Comment #91
grimreaperFor https://www.drupal.org/node/2179473#comment-8744327, Yeah, very lucky :), no code fix needed
It was the test added with https://www.drupal.org/node/2277045#comment-10092610, do you see another test for that feature ?
I begin to feel the pleasure to close an issue that has been opened more than an year ago :D
Comment #92
digitgopher commentedWhat is the status here? It is not clear to me what work is left to do.
Comment #94
grimreaperHello digitgopher,
I had to merge a last change. I waited any comment.
As nobody sees another test to implements since one week. I close the issue.
I update the issue summary so it is clear there is nothing more to do.
Thanks all.