You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 9, 2023. It is now read-only.
These happens because new entries in the initial db (the instance_permissions entry 'sponsors-view' and the chapter permission 'event-subscription-manage' in this case) were not added to the staging db. The solution is probably to include a script to reset these tables during a deployment. If/when we allow for custom roles we will need to revisit this.
Event updates were not reflected on the home page
Unable to reproduce locally. Maybe an error was thrown while the event was being updated.
This is not adding anything to the list above, but just a reminder of the Roadmap labeled issues for post-MVP in case any of these issues need to be put on ice without being lost.
Instance owner can't see sponsor page, because the sponsor permission doesn't exist in the database, so its value isn't connected to the instance owner
Issues uncovered by internal testing
These happens because new entries in the initial db (the instance_permissions entry 'sponsors-view' and the chapter permission 'event-subscription-manage' in this case) were not added to the staging db. The solution is probably to include a script to reset these tables during a deployment. If/when we allow for custom roles we will need to revisit this.
Unable to reproduce locally. Maybe an error was thrown while the event was being updated.
The 'subscribe' button should stay enabled, but the default assumption is that someone does not want notifications at this point.
For now I think an email (respecting your notification preferences) will be fine.
Short term solution: don't show the modal to logged out users.
Long term solution: show it after they complete the login flow.
Possibly not something we can solve before launching the MVP, but it's definitely something we'll need to address
Let's see how annoying this is when everyone is getting emails from both Chapter and Google.
Currently the dashboard appears in the menu and you can see http://localhost:3000/dashboard/chapters, http://localhost:3000/dashboard/events and http://localhost:3000/dashboard/venues. Also, sub dashboards like http://localhost:3000/dashboard/chapters/1/new-venue
This feels like something we should be able to solve with a dynamic route that rejects anyone without admin or owner permissions.
The text was updated successfully, but these errors were encountered: