FACES User Role - Error Message for Updating Interest

[dcieslicki]

1. Login as a FACES User.
2. Go to Account Details > Billing Summary
3. Under Billing Summary, information for specific payments is only appearing under these two rows: -----CSRS Post 10/82 Deposit -----CSRS Pre 10/82 Deposit
4. If applicable, it should appear under other rows as well, if the payment was made towards that row.
5. If you click "Update Interest", it'll throw an error message "the authorization has failed".

[pfilippi24]

CAn't reproduce this bug. Billing summary table can have values in every row and "Update Interest" calculates fine.

Can you give more details about this bug? For example which faces user was used?

[pizza-and-dog]

Please try it using the "faces_user" below, and here's the full list of ID/PW's for reference: user name="administrator" password="123456" user name="rio_user" password="123456" user name="faces_user" password="123456" user name="financial_supervisor" password="123456" user name="financial_technician" password="123456" user name="information_technician" password="123456" > user name="receivables_supervisor" password="123456" user name="receivables_technician" password="123456" user name="service_credit_data_entry_technician" password="123456" user name="view_only_user" password="123456" user name="service_credit_reviewer" password="123456" user name="service_credit_specialist" password="123456"

[pfilippi24]

Ah, I see. After looking at the configuration files of the faces project, "faces_user" is actually no faces user.

[pizza-and-dog]

I'm sorry can you clarify please?

[pfilippi24]

I'm sorry. The FACES application has its own set of users configured and faces_user is not part of it. I'll post the relevant content of spnego.xml from the FACES config folder below:

sec:user name="user1" password="123456" authorities="ROLE_USER,ROLE_SUPERVISOR" sec:user name="user2" password="123456" authorities="ROLE_USER" sec:user name="user3" password="123456" authorities="ROLE_USER,ROLE_SUPERVISOR" sec:user name="user4" password="123456" authorities="ROLE_USER,ROLE_SUPERVISOR" sec:user name="user5" password="123456" authorities="ROLE_USER,ROLE_SUPERVISOR" sec:user name="faces@OPM.EC2.INTERNAL" password="123456" authorities="ROLE_USER,ROLE_SUPERVISOR"

If you try the actions described in the bug description using one of these users, it will work fine without authorization error

[pizza-and-dog]

Thanks, then as part of this ticket, simply just copy the user configuration to "faces_user" so that it doesn't error out. Regarding the other items, don't worry about that since Service History is being worked on in the Part 2 assembly.

[kinfkong]

I can reproduce this bug login SCRD application with faces_user. but pfilippi24 is mentioning the FACES application. Can you confirm that this bug is pointed to FACES application or SCRD application? Thanks.

[pizza-and-dog]

Ah yes, I got confused. The issue is with the FACES app, not the SCRD app. Bundled into the system is a FACES app that interfaces with SCRD. The issue is with the faces_user in the SCRD app.

[kinfkong]

? it seems that you say 2 conflict sentence: "The issue is with the FACES app, not the SCRD app." "The issue is with the faces_user in the SCRD app."

Now, let me explain what is actually going on.

the users in the pfilippi24's configure file is not actually used, because those are just sample configured for Windows_Security_Integration only. If we are not logged in as Windows Security Integration, we are actually using the user info in postgreSQL DB.

since we have the same data for FACES app and SCRD app in db, so actually, they have all the same users.

But, the user name "FACES user" is not of a role "FACES" role, so "FACES user" cannot login the FACES app. "user5" is OK to login the FACES. for user5, it is a "FACES user" and can login and it works fine in update interest (no authorized error popup).

"FACES user" can login the SCRD, but it does not have the permission to do the updateInterest action, so the authorized error popup.

so, what do you expect us to do?

[pizza-and-dog]

Sorry was on mobile device. To confirm:

1. The issue is with the SCRD app.
2. The errors are occurring for the faces_user in the SCRD app.
3. The error is NOT with the FACES app.

Regarding the users:

1. Give "faces_user" a "FACES" role. The "faces_user" should be able to log into both the SCRD app and the FACES app.
2. Once this is done, as long as "faces_user" can update the interest, then we're all good.

Meeting 1 & 2 above will be be considered as "completing" this ticket.

[pizza-and-dog]

Fixed, sending the code to OPM for verification.