Issue Details (XML | Word | Printable)

Key: MDL-15374
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: Eloy Lafuente (stronk7)
Reporter: Todd Thornton
Votes: 1
Watchers: 0
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Moodle

Payments Button Appears in Profile When It Should Not?

Created: 24/Jun/08 01:51 AM   Updated: 26/Jun/08 10:29 PM
Component/s: Administration
Affects Version/s: 1.9.1
Fix Version/s: None

URL: http://moodle.org/mod/forum/discuss.php?d=97747#p441442
Participants: Eloy Lafuente (stronk7), Ethem Evlice, Matt Campbell and Todd Thornton
Security Level: None
Affected Branches: MOODLE_19_STABLE


 Description  « Hide
I've tried to apply a patch for MDL-13835 to hide the courses someone is enrolled in from other students who have no need to access that information. In testing this, it seems there's not any type of check for when the payment button appears. The payment button appears when you click on another student's profile and while their payments don't appear it would seem there's no need for the payment button to appear at all when clicking on another students profile. I'm also including a link to the forum discussion on this topic.
http://moodle.org/mod/forum/discuss.php?d=97747#p441442

Here's an update from my original post. I obviously didn't understand the default behavior, but I still think this might need to be addressed.

After testing some more in the default install, when clicking on another students profile the payments button seems to reflect the payments of the student who is logged in, not the student whose profile is being clicked on. I didn't catch it before because I typically use the same test amounts when I run payments through under my own name using different user accounts and the one account I hadn't run a payment through yet. I just looked at my 1.6 install and it works exactly the same way. I've never noticed it before because I've never had the ability to change/add user profile fields.

I think if someone uses the original patch from Mike it will do exactly what was intended and that's hide the courses enrolled in from other students. I still don't think the payments button is necessary when looking at someone else's profile and there's no reason for it to appear because it's somewhat of a mixed message. The messages button applies to the student profile your looking at and the payments button right next to it applies to the student logged in, but it appears that's the default behavior.

Todd



 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
Matt Campbell added a comment - 25/Jun/08 10:52 PM
My answer in the forums was to add a capability check for enrol/authorize:managepayments, which resolves the issue but maybe not in the best way.

According to what Todd is reporting, the Payments button shows up on all profiles in the course, if Authorize.net is used as a payment type for the course. If a user clicks on the button, no matter who's profile it is, they get their own payment history, not the payment history of the user they are clicking on. It looks like /enrol/authorize/locallib.php does a check if the user has the enrol/authorize:managepayments capability, they see the payments for the user they clicked on. If not, they see their own.

I think proper behavior would be to:

If you are looking at your own profile, you will see the Payments button and will be able to see your payments.
If you have the enrol/authorize:managepayments capability, you will see it on all profiles will see that user's payments.
If you do not have the enrol/authorize:managepayments capability and you are looking at another user's profile, you do not see the Payments button.


Ethem Evlice added a comment - 26/Jun/08 10:16 PM
user/view.php line: 495

Adding isguest()==false to the line, solves this problem...

The new line is:

if (isguest() == false && ($course->enrol == 'authorize' || (empty($course->enrol) && $CFG->enrol == 'authorize'))) {

Your last 3 behaviors as it.


Ethem Evlice added a comment - 26/Jun/08 10:29 PM
/enrol/authorize/locallib.php checks enrol/authorize:managepayments capability correctly.

if an normal user sees, he sees their payment history without payment management.
if an admin user (with enrol/authorize:managepayments capability) sees, he sees user's payment history and can manage payments.
if normal user sees another user's payment it requires enrol/authorize:managepayments capability. So no one can see other payment.

The problem is just appearing 'Payment' button and adding isguest() solves this problem.