Bug: Admins can edit Contact Type Groups across Organizations

[FireLemons]

Impacted User Types

• admins

Expected Behavior

A warning showing "Sorry, you are not authorized to perform that action." is shown before an admin can edit a contact type group across an organization.

How to Replicate

ex:

1. • Log in as an admin.
2. • Click on "Edit Organization" in the left sidebar.
3. • Scroll down to under the header "Manage Contact Types".
4. • Click "Edit" on one of the contact types.
5. • Copy the link to the page.
6. • Log out.
7. • Log in as an admin from a different org [email protected]
8. • Paste the link and visit it.
9. • Edit the name of the Contact Type Group.
10. • Log in as the original admin again.
11. • Navigate to the Contact Types again under "Edit Organization"
12. • See that the edit from the admin from the other org affected the Contact Type Group from this organization.

Login Details:

Login Emails:

• [email protected] view site as a volunteer
• [email protected] view site as a supervisor
• [email protected] view site as an admin
• [email protected] view site as an all casa admin
  • go to /all_casa_admins/sign_in

password for all users: 12345678

Questions? Join Slack!

We highly recommend that you join us in slack #casa channel to ask questions quickly. And discord for office hours (currently Tuesday 5-7pm Pacific), stakeholder news, and upcoming new issues.

[CodeGovindz]

hey @FireLemons can I work on it ?

[compwron]

@CodeGovindz go for it :)

[FireLemons]

@CodeGovindz I suspect we may have similar bugs for the other sections of the "Edit Organization" page. If you want, you can test out the other sections (Contact Types, Hearing Types, Judge...) and if they're bugged you'll be able to apply the same fix for those sections.

[github-actions[bot]]

This issue has been inactive for 250 hours (10.42 days) and will be unassigned after 110 more hours (4.58 days). If you have questions, please

If you are still working on this, comment here to tell the bot to give you more time

[github-actions[bot]]

This issue has been inactive for 370 hours (15.42 days) and is past the limit of 360 hours (15.00 days) so is being unassigned.You’ve just been unassigned from this ticket due to inactivity – but feel free to pick it back up (or a new one!) in the future! Thank you again for your contribution to this project.

[thebrowski]

Hi, I just started looking at the project today, to it's entirely possible I'm missing something, but here is what I found after doing some digging.

I was unable to replicate, specifically step 12, which states the change made by user 2 can be seen when user 1 accesses their org.

But I did notice something that could be improved in the CasaOrgController. Notably, when we set @casa_org we are not using, the id provided in the route, we're getting it at the ApplicationController level via the Organizational concern (code)

This means that if you're logged in as [email protected], even if you try to access another org like /casa_org/2/edit you will still be looking at your own CasaOrg. In fact, the id parameter here doesn't matter at all, if you access /casa_org/thiscouldbeliterallyanything/edit you will still see your own org. The update endpoint behaves the same way, so even though you're sending an update request to a different org, you are updating your own org.

There are a couple of ways to approach this. If now or in the future we want a CasaAdmin to have access to multiple CasaOrgs, we should set the org based on the id in the URL. Another option would be to use a singular resource in the routes file, so the path would be /casa_org/edit (no id)

[compwron]

Hi, I just started looking at the project today, to it's entirely possible I'm missing something, but here is what I found after doing some digging.

I was unable to replicate, specifically step 12, which states the change made by user 2 can be seen when user 1 accesses their org.

But I did notice something that could be improved in the CasaOrgController. Notably, when we set @casa_org we are not using, the id provided in the route, we're getting it at the ApplicationController level via the Organizational concern (code)

This means that if you're logged in as [email protected], even if you try to access another org like /casa_org/2/edit you will still be looking at your own CasaOrg. In fact, the id parameter here doesn't matter at all, if you access /casa_org/thiscouldbeliterallyanything/edit you will still see your own org. The update endpoint behaves the same way, so even though you're sending an update request to a different org, you are updating your own org.

There are a couple of ways to approach this. If now or in the future we want a CasaAdmin to have access to multiple CasaOrgs, we should set the org based on the id in the URL. Another option would be to use a singular resource in the routes file, so the path would be /casa_org/edit (no id)

We never want a CasaAdmin to be able to access any org other than their own org.

[compwron]

re this - I think it would be better to redirect the url to your own org if you try to go to some other org.

[compwron]

Does this still need doing?

[github-actions[bot]]

This issue has been open without changes for a long time! What's up?