Bug 25090 - Moderate OPAC self-registrations before a patron account is activated
Summary: Moderate OPAC self-registrations before a patron account is activated
Status: Signed Off
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Aleisha Amohia
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-09 03:22 UTC by Alex Buckley
Modified: 2025-06-16 04:44 UTC (History)
8 users (show)

See Also:
GIT URL:
Change sponsored?: Sponsored
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
This enhancement allows libraries to choose how to moderate OPAC self-registrations before a patron's account is activated. It updates the PatronSelfRegistrationVerifyByEmail system preference with verification options: * No verification required * Patron verification required * Library verification required It also adds a new notice that is sent to library staff if library verification is selected: OPAC_REG_VERIFY_LIB.
Version(s) released in:
Circulation function:


Attachments
Bug 25090: Add sysprefs to define destination of OPAC self reg verification emails (39.06 KB, patch)
2020-04-13 14:32 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Add sysprefs to define destination of OPAC self reg verification emails (51.41 KB, patch)
2020-04-23 05:47 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Add sysprefs to define destination of OPAC self reg verification emails (51.54 KB, patch)
2020-04-23 06:34 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: OPAC Template changes (5.17 KB, patch)
2020-05-05 21:28 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Add 2 new sysprefs allowing libraries to approve OPAC registrations (6.98 KB, patch)
2020-05-05 21:28 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Added 3 new notices (36.15 KB, patch)
2020-05-05 21:28 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Allow libraries to verify OPAC self registrations (20.00 KB, patch)
2020-05-05 21:29 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Allow libraries to verify OPAC self registrations (20.87 KB, patch)
2020-05-05 21:56 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Added 3 new notices (36.76 KB, patch)
2020-05-18 03:29 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Allow libraries to verify OPAC self registrations (20.87 KB, patch)
2020-05-18 03:30 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Remove references to PatronSelfRegistrationVerifyByEmail syspref (3.98 KB, patch)
2020-05-25 04:45 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: OPAC Template changes (5.96 KB, patch)
2020-10-26 06:32 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Add 2 new sysprefs allowing libraries to approve OPAC registrations (7.02 KB, patch)
2020-10-26 06:33 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Added 3 new notices (35.23 KB, patch)
2020-10-26 06:33 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Allow libraries to verify OPAC self registrations (20.93 KB, patch)
2020-10-26 06:34 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Remove references to PatronSelfRegistrationVerifyByEmail syspref (3.91 KB, patch)
2020-10-26 06:34 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 25090: Update PatronSelfRegistrationVerifyByEmail to include choices (5.60 KB, patch)
2024-11-04 02:20 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Add OPAC_REG_VERIFY_LIB notice (5.68 KB, patch)
2024-11-04 02:20 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090 [WIP]: Redirect OPAC self reg verification email to the library (10.16 KB, patch)
2024-11-04 02:20 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Update PatronSelfRegistrationVerifyByEmail to include choices (5.60 KB, patch)
2024-11-04 02:24 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Add OPAC_REG_VERIFY_LIB notice (5.68 KB, patch)
2024-11-04 02:24 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090 [WIP]: Redirect OPAC self reg verification email to the library (10.16 KB, patch)
2024-11-04 02:24 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Update PatronSelfRegistrationVerifyByEmail to include choices (5.60 KB, patch)
2024-11-05 01:44 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Add OPAC_REG_VERIFY_LIB notice (4.49 KB, patch)
2024-11-05 01:44 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Redirect OPAC self reg verification email to the library (17.68 KB, patch)
2024-11-05 01:44 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Update PatronSelfRegistrationVerifyByEmail to include choices (5.65 KB, patch)
2024-11-07 13:38 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 25090: Add OPAC_REG_VERIFY_LIB notice (4.49 KB, patch)
2024-11-07 13:38 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 25090: Redirect OPAC self reg verification email to the library (17.79 KB, patch)
2024-11-07 13:38 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 25090: Update PatronSelfRegistrationVerifyByEmail to include choices (4.97 KB, patch)
2025-06-05 05:50 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Update OPAC_REG notice to include verification link (5.21 KB, patch)
2025-06-05 05:51 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Enable library to verify OPAC self registrations (19.03 KB, patch)
2025-06-05 05:51 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Enable library to verify OPAC self registrations (19.03 KB, patch)
2025-06-05 06:05 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 25090: Update PatronSelfRegistrationVerifyByEmail to include choices (5.01 KB, patch)
2025-06-15 23:56 UTC, David Nind
Details | Diff | Splinter Review
Bug 25090: Update OPAC_REG notice to include verification link (5.25 KB, patch)
2025-06-15 23:56 UTC, David Nind
Details | Diff | Splinter Review
Bug 25090: Enable library to verify OPAC self registrations (19.07 KB, patch)
2025-06-15 23:56 UTC, David Nind
Details | Diff | Splinter Review
Bug 25090: (follow-up) System preference description (2.49 KB, patch)
2025-06-16 04:19 UTC, David Nind
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Buckley 2020-04-09 03:22:59 UTC
Currently libraries can use the PatronSelfRegistrationVerifyByEmail syspref to restrict self registering users from being able to access the OPAC after registering until they have acknowledged the email sent by Koha. 

If that syspref is disabled then self registering users will be able to login to the OPAC straight after filling in the self registration form. 

It would be good if libraries had further control over what users can login to the OPAC. 
Why? Many online resources (e.g. 3rd party database access) require only OPAC login to be able to be accessed. Special libraries may want to limit OPAC login access only to those users within their organisation as these online resources do charge the libraries on a usage basis. 

How can further control over what users trying to self register can access the OPAC be achieved whilst keeping the default, current Koha behaviour?

1. Ensure 'PatronSelfRegistrationVerifyByEmail' syspref is set to 'Require'

2. Add a new syspref 'PatronSelfRegistrationVerificationRecipient'(This dropdown syspref would allow libraries to choose):

* email address of branch
* KohaAdminEmailAddress
* Requesting user

If email address of branch or KohaAdminEmailAddress then the verification email generated after the user has submitted the registration form will go to the library. The email will contain some details entered by the patron, so the library can confirm if they are happy that the registering user is able to login to the OPAC then they will acknowledge the email (click on the opac-registration-verify.pl link) which will actually make the patron account.
Comment 1 Alex Buckley 2020-04-13 14:32:37 UTC Comment hidden (obsolete)
Comment 2 Alex Buckley 2020-04-13 14:33:47 UTC
This is not quite ready for testing I still have to write up test plans and add another followup patch to tidy off some functionality. Will update when ready to test.
Comment 3 Alex Buckley 2020-04-23 05:47:00 UTC Comment hidden (obsolete)
Comment 4 Alex Buckley 2020-04-23 06:34:32 UTC Comment hidden (obsolete)
Comment 5 Katrin Fischer 2020-04-29 06:11:00 UTC
What a test plan!

If I understood correctly, if you turn on the feature to send the verification to the library, you can't use the email verification for the patrons at the same time.

We have new prefs here and a new notice template - would it be a big step to make this a separate feature? Maybe to happen after the patrons have verified their email address?

The email verification also serves as kind of a SPAM protection, it ensures you only have to deal with registrations that have gone through a first step and prevents (to some extend) people from registering under other people's email addresses. I think it might be helpful to have this in addition to further verification by staff as is the use case here.

I guess one of the problems here is that you can't really keep patrons from logging in, once they have been added to the database? Using a restriction would be a logical thing, but I think it would not have the desired effect right now.
Comment 6 Alex Buckley 2020-04-29 07:55:58 UTC
Hi Katrin, 

Yes the test plan was quite something to write up!

Thanks very much for your questions and thoughts, much appreciated :)

Your absolutely correct, if you turn on the feature to send verification to library (in new PatronSelfRegistrationVerificationRecipient syspref) then you can't use email verification for the patrons at the same time.

Yes once a patron is added to the database you can't stop them from logging in. However when the existing PatronSelfRegstrationVerifyByEmail syspref is enabled when a user registers a row is only added into borrower_modifications database table. At this point the user cannot login. 

Only after the patron has clicked the link in the verification email does Koha remove the row from borrower_modification, add a row to borrowers table and give it a borrowers.userid, allowing them to login.

So the verification process does provide a way of delaying when a user can login. So with our patch the registering patron record is in the borrower_modifications table (i.e. can't login) until the library staff member clicks the verification email link. Once they've clicked the link the registering patron is added to borrowers table and so can now login. 

Just to clarify regarding making this a separate feature, would that entail simply changing the workflow to occur like outlined below or would new sysprefs or staff client interfaces be required?

1. User registers in OPAC -> Record added to borrower_modifications table
2. Verification email sent to user
3. If verification email link clicked by user then notice emailed to library to verify 
4. Librarian clicks verification link in library notice -> Record added to borrowers table
5. User is emailed password reset link whereupon they can change their password and login to OPAC

I am more than happy to make this change but would just like to clarify first what you feel would be needed :)

Many thanks,
Alex
Comment 7 Katrin Fischer 2020-05-03 22:45:19 UTC
Hi Alex, 

I think the workflow you describe would work (while hopefully not disrupting your work too much)

A possible thing (for another day and bug report) could be a report/hint on the dashboard for patrons requiring verification. But I think the emails work well as a first implementation. 

About configuration: I am not sure what would be easier, have PatronSelfRegistrationVerifyByEmail with 4 options (none, one, the other, both) or have 2 prefs instead for each that you can turn on/off separately. I am slightly leaning to the latter, but would name them similar so they show up together... or even group them into one line in the editor?
Comment 8 Alex Buckley 2020-05-04 03:21:28 UTC
Hi Katrin, 

Thanks very much for your feedback, yes I agree having a hint or report in the dashboard would be a good later enhancement on a different bug report. 

Yes I think the two prefs on the same line in the editor (replacing PatronSelfRegistrationVerifyByEmail) could be named:

* PatronSelfRegistrationVerifyByEmailToLibrary - Email address of branch / KohaAdminEmailAddress  / Don't require
* PatronSelfRegistrationVerifyByEmailToPatron - Require / Don't require

I think for simplicities sake it would be good to include the options from PatronSelfRegistrationVerificationRecipient into PatronSelfRegistrationVerifyByEmailToLibrary (i.e. have 3 options so the librarian can choose not just to enable but defined where the email should be sent) so we limit the number of new sysprefs added. 

I am working on those changes now. 

Thanks,
Alex
Comment 9 Alex Buckley 2020-05-05 21:28:03 UTC Comment hidden (obsolete)
Comment 10 Alex Buckley 2020-05-05 21:28:21 UTC Comment hidden (obsolete)
Comment 11 Alex Buckley 2020-05-05 21:28:47 UTC Comment hidden (obsolete)
Comment 12 Alex Buckley 2020-05-05 21:29:08 UTC Comment hidden (obsolete)
Comment 13 Alex Buckley 2020-05-05 21:56:51 UTC Comment hidden (obsolete)
Comment 14 Alex Buckley 2020-05-05 22:03:51 UTC
Hi Katrin, 

I have made the functionality changes to the patchset as you suggested, and implemented the two new sysprefs PatronSelfRegistrationVerifyByEmailToLibrary and PatronSelfRegistrationVerifyByEmailToPatron on the same line in the editor. 

So now there are 4 possible email verification workflow scenarios:

1) library verification = disabled & patron verification = disabled :
   1a) Patron submits OPAC self reg form
   1b) Patron account created immediately

2) library verification = enabled & patron verification = disabled :
   2a) Patron submits OPAC self reg form
   2b) Koha sends notice to library to review registration
   2c) Library approves reg by clicking verification link in notice
   2d) Patron account is created
   2e) Password reset link emailed to patron

3) library verification = disabled & patron verification = enabled :
   3a) Patron submits OPAC self reg form
   3b) Koha sends verification email to patron
   3c) Patron clicks verification link in notice
   3d) Patron account is created

4) library verification = enabled & patron verification = enabled :
   4a) Patron submits OPAC self reg form
   4b) Koha sends verification email to patron to verify email
   4c) Patron clicks verification link in notice
   4d) Koha sends notice to library to review registration
   4e) Library approves reg by clicking verification link in notice
   4f) Patron account created
   4g) Password reset link emailed to patron

The logic changes I have made have been in opac-memberentry.pl and opac-registration-verify.pl please let me know if you think they should be moved to a Koha object or the C4 namespace. 

Thanks,
Alex
Comment 15 Alex Buckley 2020-05-18 03:29:43 UTC Comment hidden (obsolete)
Comment 16 Alex Buckley 2020-05-18 03:30:18 UTC Comment hidden (obsolete)
Comment 17 Alex Buckley 2020-05-18 03:31:06 UTC Comment hidden (obsolete)
Comment 18 Alex Buckley 2020-05-25 04:45:25 UTC Comment hidden (obsolete)
Comment 19 Lisette Scheer 2020-10-23 22:39:03 UTC Comment hidden (obsolete)
Comment 20 Alex Buckley 2020-10-26 06:32:53 UTC Comment hidden (obsolete)
Comment 21 Alex Buckley 2020-10-26 06:33:22 UTC Comment hidden (obsolete)
Comment 22 Alex Buckley 2020-10-26 06:33:47 UTC Comment hidden (obsolete)
Comment 23 Alex Buckley 2020-10-26 06:34:14 UTC Comment hidden (obsolete)
Comment 24 Alex Buckley 2020-10-26 06:34:38 UTC Comment hidden (obsolete)
Comment 25 Alex Buckley 2020-10-26 06:35:38 UTC
Rebased against master.
Comment 26 David Nind 2021-08-09 10:50:00 UTC Comment hidden (obsolete)
Comment 27 Aleisha Amohia 2024-11-04 02:20:42 UTC Comment hidden (obsolete)
Comment 28 Aleisha Amohia 2024-11-04 02:20:46 UTC Comment hidden (obsolete)
Comment 29 Aleisha Amohia 2024-11-04 02:20:49 UTC Comment hidden (obsolete)
Comment 30 Aleisha Amohia 2024-11-04 02:24:20 UTC Comment hidden (obsolete)
Comment 31 Aleisha Amohia 2024-11-04 02:24:24 UTC Comment hidden (obsolete)
Comment 32 Aleisha Amohia 2024-11-04 02:24:27 UTC Comment hidden (obsolete)
Comment 33 Aleisha Amohia 2024-11-05 01:44:49 UTC Comment hidden (obsolete)
Comment 34 Aleisha Amohia 2024-11-05 01:44:52 UTC Comment hidden (obsolete)
Comment 35 Aleisha Amohia 2024-11-05 01:44:55 UTC Comment hidden (obsolete)
Comment 36 Owen Leonard 2024-11-07 13:38:52 UTC Comment hidden (obsolete)
Comment 37 Owen Leonard 2024-11-07 13:38:55 UTC Comment hidden (obsolete)
Comment 38 Owen Leonard 2024-11-07 13:38:57 UTC Comment hidden (obsolete)
Comment 39 Owen Leonard 2024-11-07 13:47:27 UTC
It definitely feels odd to have staff go to the OPAC to complete the process. It might be nice to, in the future, bring that operation into the staff interface somehow.

I don't know what the sponsoring library's workflow is, but I can see difficulty in the process of notifying the patron of their account details. Copying the info into an email would not be great. Perhaps an option to directly trigger a "forgot password" email to the patron from the verification screen?

Does the notice need to be updated to remove the old << >> syntax in favor of TT? I don't know if we're requiring that for new patches?
Comment 40 Aleisha Amohia 2024-11-07 19:13:05 UTC
(In reply to Owen Leonard from comment #39)
> It definitely feels odd to have staff go to the OPAC to complete the
> process. It might be nice to, in the future, bring that operation into the
> staff interface somehow.

Agree - was hoping that could be a follow-up change!

> 
> I don't know what the sponsoring library's workflow is, but I can see
> difficulty in the process of notifying the patron of their account details.
> Copying the info into an email would not be great. Perhaps an option to
> directly trigger a "forgot password" email to the patron from the
> verification screen?
> 

That's a good idea, if it's a blocker I might have enough time to work on this.

> Does the notice need to be updated to remove the old << >> syntax in favor
> of TT? I don't know if we're requiring that for new patches?

The borrower_modifications table isn't available to the TT syntax yet! So had to use the << >> syntax.
Comment 41 Jonathan Druart 2025-01-23 12:20:03 UTC
1. New notice templates should use the TT syntax
https://wiki.koha-community.org/wiki/Coding_Guidelines#NOTICE1:_Default_Notices_should_now_be_writing_using_template_toolkit

2. Changes to .pm should be covered by tests

3. At first glance I'd say that the changes for OPAC_REG_VERIFY_LIB should go close to OPAC_REG (which is nicely placed in a module, Koha::Patron->notify_library_of_registration)
Code seems duplicated.
Comment 42 Aleisha Amohia 2025-06-05 05:50:54 UTC Comment hidden (obsolete)
Comment 43 Aleisha Amohia 2025-06-05 05:51:00 UTC Comment hidden (obsolete)
Comment 44 Aleisha Amohia 2025-06-05 05:51:04 UTC Comment hidden (obsolete)
Comment 45 Aleisha Amohia 2025-06-05 06:05:43 UTC Comment hidden (obsolete)
Comment 46 David Nind 2025-06-15 23:56:26 UTC
Created attachment 183266 [details] [review]
Bug 25090: Update PatronSelfRegistrationVerifyByEmail to include choices

Signed-off-by: David Nind <david@davidnind.com>
Comment 47 David Nind 2025-06-15 23:56:40 UTC
Created attachment 183267 [details] [review]
Bug 25090: Update OPAC_REG notice to include verification link

Signed-off-by: David Nind <david@davidnind.com>
Comment 48 David Nind 2025-06-15 23:56:53 UTC
Created attachment 183268 [details] [review]
Bug 25090: Enable library to verify OPAC self registrations

This enhancement changes the PatronSelfRegistrationVerifyByEmail system preference to have the following options:

* don't require (same as 0 previously)
* patron verifies (same as 1 previously)
* library verifies, based on the EmailPatronRegistrations syspref setting

If the syspref is set to "based on the EmailPatronRegistrations" setting, this allows the library to redirect the verification email so that they can essentially moderate accounts that self-register via the OPAC.

This enhancement also introduces a new notice OPAC_REG_VERIFY_LIB which includes the new account's details and the verification link.

When the library confirms a self-registered account, this triggers a password recovery email to the new patron.

To test:

1. Apply patches, install database updates, and restart services (if using ktd, do `koha-upgrade-schema kohadev` then `restart_all`)
2. Go to the staff interface, Koha administration, system preferences. Go to the OPAC tab and find the self-registration and modification section.
3. By default, the PatronSelfRegistrationVerifyByEmail is set to "not required". Change this to "must verify themselves via email".
4. Change EmailPatronRegistrations to anything other than "none" (we're not specifically testing this functionality).
5. Confirm that PatronSelfRegistration is set to "Allow", as are other required preferences (these should be set by default in ktd).

6. Go to the OPAC in another window. You may be automatically logged in, if so, log out.
7. On the homepage, click the "Create an account" link under the login section.
8. Fill in the required fields and submit.

9. In your commandline, go to the database and view the results from the message_queue table (`koha-mysql kohadev` then `select * from message_queue\G`)

10. Confirm there is a queued message to the new account holder with a verification link. Open the verification link in your browser (you may need to swap out the OPACBaseURL if that isn't set correctly)
11. Confirm the account's registration.
12. Repeat step 9. Confirm there is a queued message to whoever you set EmailPatronRegistrations to, confirming a new account was created.

13. Go to your staff interface tab (you may need to log in again).
14. Go to the staff interface, Koha administration, system preferences. Go to the OPAC tab and find the self-registration and modification section.
15. Change PatronSelfRegistrationVerifyByEmail to "must be verified via email sent to EmailPatronRegistrations"

16. Repeat steps 6-9.
17. Confirm there is a queued message to the EmailPatronRegistrations setting with a verification link. Open the verification link in your browser (you may need to swap out the OPACBaseURL if that isn't set correctly)
18. Confirm the account's registration.
19. Confirm the screen says a password recovery email has been generated.
20. Repeat step 9. Confirm there is a queued recovery email message to the new patron.

21. Confirm tests pass t/db_dependent/Koha/Patron/Modifications.t

Sponsored-by: Mental Health Education & Resource Centre
Signed-off-by: David Nind <david@davidnind.com>
Comment 49 David Nind 2025-06-16 04:19:44 UTC
Created attachment 183269 [details] [review]
Bug 25090: (follow-up) System preference description

Update the PatronSelfRegistrationVerifyByEmail system
preference description.

Signed-off-by: David Nind <david@davidnind.com>
Comment 50 David Nind 2025-06-16 04:44:38 UTC
I've added a follow-up to update the PatronSelfRegistrationVerifyByEmail system
preference description.

It looked a little odd to have the options first without some sort of introduction, and the options starting in lowercase.

I'm not sure that I got it totally right, but I think it is an improvement.

Testing notes (using KTD):
1. The tests pass, but there are errors (these are the same before the patches, so not related to this bug):

prove t/db_dependent/Koha/Patron/Modifications.t
t/db_dependent/Koha/Patron/Modifications.t .. 1/8 DBIx::Class::Storage::DBI::insert(): Missing value for primary key column 'borrowernumber' on BorrowerModification - perhaps you forgot to set its 'is_auto_increment' attribute during add_columns()? Treating 'borrowernumber' implicitly as an autoinc, and attempting value retrieval at /kohadevbox/koha/Koha/Object.pm line 174
t/db_dependent/Koha/Patron/Modifications.t .. 5/8 DBIx::Class::Storage::DBI::insert(): Missing value for primary key column 'verification_token' on BorrowerModification - perhaps you forgot to set its 'is_auto_increment' attribute during add_columns()? Treating 'verification_token' implicitly as an autoinc, and attempting value retrieval at /kohadevbox/koha/Koha/Object.pm line 174
t/db_dependent/Koha/Patron/Modifications.t .. ok   
All tests successful.
Files=1, Tests=8,  2 wallclock secs ( 0.01 usr  0.00 sys +  1.60 cusr  0.40 csys =  2.01 CPU)
Result: PASS