Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RES-1633 unapproved events #598

Merged
merged 12 commits into from Feb 20, 2023
Merged

RES-1633 unapproved events #598

merged 12 commits into from Feb 20, 2023

Conversation

edwh
Copy link
Collaborator

@edwh edwh commented Dec 19, 2022

This builds on RES-1101, so the diffs will look wrong until that is merged.

Unapproved events (and devices of those events) should be visible to:

  • admins
  • network coordinators
  • relevant hosts

So:

  1. Add a userCanSeeEvent method in User to contain this logic.
  2. In ExportController, add this logic and a new approved column into the export.
  3. In Search, add this logic.
  4. Return the approved property in the API for Party and PartySummary.
  5. Remove some debug in EditWordpressPostForEvent
  6. Fix a bad query in Party::ofTheseGroups.
  7. In CalendarEventsController add this logic and fix up the event status, including for cancelled events.
  8. Test this.

@sonarcloud
Copy link

sonarcloud bot commented Dec 19, 2022

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability E 2 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 24 Code Smells

No Coverage information No Coverage information
0.5% 0.5% Duplication

# Conflicts:
#	tests/Feature/Events/ExportTest.php
Copy link
Contributor

@ngm ngm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, it adds a method for checking whether a user can see an event based on event and group approval. And then amends Calendar, Export, and Search to take this into account.

  • Added in a permission check for Calendar Events, which seems good.
  • Wondered about ExportController::devices - one place it is called is https://therestartproject.org/download-dataset/ which is a public call - so I wondered if the permission check in userCanSeeEvent is added, whether this would then return no data here. But as discussed it will still be fine, as it will return devices from events where both the events and groups are approved.
  • I get a 'Maximum execution time of 60 seconds exceeded' when trying http://restarters.test:8000/export/devices locally with the new code change - I guess the extra permission check slows it down? /export/devices completes if I run it off develop.
  • Seems correct to filter Search::parties by userCanSeeEvent.
  • approved is returned via the API, but events are not filtered dependent on approved. This is correct, as we let the client side decide what they want to do.

@sonarcloud
Copy link

sonarcloud bot commented Feb 20, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 18 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@edwh edwh merged commit c8ec5a5 into develop Feb 20, 2023
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants