Added 2024-08-28 meeting notes.

docs/team/meeting-notes/2024/08/2024-08-28-meeting-notes.md

@@ -0,0 +1,150 @@
+# 2024-08-28 maintainer meeting
+
+## Record summaries update and plan
+
+- We've already decided won't have record summaries editable for the "RC", but we do want them editable for the beta.
+- Brent will explain the plan for what needs to be implemented to make summaries editable, in case it needs to be implemented when he's out.
+- Goal for meeting:
+    - Agree on plan.
+    - Decide who will implement if we need to when Brent is out.
+
+### Discussion
+- Team is in agreement that it's fine to have record summaries not be editable for the "RC".
+- Sean will look into the bare minimum change we can make to the UI that makes it clear that record summaries aren't editable / won't lead the user down a dead end. 
+    - Doesn't have to be a perfect UX.
+    - Could be as simple as hiding a section inside the table inspector.
+- We will need to communicate to users in the RC release notes that this feature is temporarily not working.
+- Sean will be the person to implement once Brent is gone.
+- Brent, Anish and Sean will discuss technical implementation details in a separate call.
+
+## Installation work plan
+
+Brent investigated how well installation is working with the new permissions setup, [his report is here](https://hackmd.io/TTrZ6EPiQrKmmu3Vb0FHEg) (doc is private to Mathesar staff).
+
+Good news: we'll need to make fewer changes than originally anticipated.
+
+Goal of discussion: figure out a clear plan for installation-related work for the initial "RC" testing release.
+
+###  Work needed for installation configuration changes
+
+How much work do we need to ensure we don't need a superuser to install Mathesar?
+
+- Not much.
+- Current docs already say you don't need to be a superuser, just a database owner.
+- We could make it even clearer, but that seems like work for the final beta, not the RC.
+- For the beta, we should audit the documentation to make sure we're explaining the permissions we need in a friendly and obvious way.
+    - 'What user you use Mathesar with' vs 'What user you install Mathesar with' needs to be explained
+    - Superuser role should be made clear
+    - We should also put some work into testing installation without a superuser
+
+### Work needed for upgrades
+
+Should we put effort into automating upgrades from 0.1.7 to RC?
+
+- We'd need some sort of wizard or clearly documented manual steps.
+- Automating it will be very hard.
+- The way we store database information has changed.
+    - Do we delete database connections and ask the user to reenter?
+        - They could lose data if they don't have their database password anymore.
+        - Not having their DB password seems like an edge case, do we need to even consider it?
+        - Even if it's an edge case, consequences are potentially dire.
+        - They'll also lose explorations and metadata connected to DBs.
+        - We could build the backup and restore function we've been talking about forever...
+    - What will the experience look like if we migrate some database information?
+        - Will we need new UI?
+        - No, the admin will see a list of databases, but they'll need to go to the roles configuration UI and configure a role.
+            - What if they don't have create role privileges?
+        - Could be a confusing experience.
+- Do we even need to support upgrades?
+    - RC is not really an "upgrade", it's a testing build.
+    - We won't be at feature parity with 0.1.7, we won't have done thorough QA.
+    - This release is not for users who want the next version of Mathesar.
+    - People shouldn't be thinking of this as an upgrade.
+
+**Conclusion**
+
+- We won't put any work into upgrades for the RC.
+- We won't be treating the RC as the "next" release.
+    - Maybe publish to a separate Docker repo, definitely don't use the "latest" tag
+    - Postgres, Python, etc. use the same Docker repo for testing builds, just use tags to differentiate
+    - We could even consider an invite-only release
+- Less work, better communicates the release purpose.
+
+### Documentation updates for "from scratch" install
+
+Brent ran into a 500 error when testing the "from scratch" install, who should work on resolving this?
+
+- This is actually an error with the static file setup, not Mathesar.
+- We don't have pre-built static files for current develop, but we will when we do the release.
+    - That should fix the error.
+- No documentation updates should be needed.
+- Our usual installation testing process for releases should be enough, it's already tracked in docs and Basecamp.
+- Anish is most likely to work on this (not because of backend expertise, just based on workload).
+
+### Documentation accuracy updates
+
+We need to go through docs.mathesar.org and ensure our documentation is accurate.
+
+- Ghislaine will update user-facing documentation.
+- One of the engineers will update admin-facing documentation, depending on availability.
+    - Should we be setting the `OWNER` role here?  https://docs.mathesar.org/installation/build-from-source/#installation-steps
+- This needs to happen before RC.
+
+### Onboarding UI changes 
+
+Do we need any changes in our onboarding user flow to account for the new permissions setup?
+
+We walked through the current process.
+- Once the user creates the superuser, they go to the database page.
+
+**Conclusion**: Nothing here blocks RC, we should probably consider improving usability for beta.
+
+### New documentation
+
+We need to make new documentation for how permissions work. Ghislaine will work on this as part of her work on user-facing documentation.
+
+### Access to Mathesar schemas for `PUBLIC` "role"
+
+The Mathesar schemas `msar` and `_msar` should both be set up so that `PUBLIC` has access.
+
+- `PUBLIC` is a pseudo role that every role on the database automatically gets.
+    - It's not shown as a role in the roles table, so needs special handling.
+- We want to set this up for current objects, but also for any object we create in those schemas in the future.
+- Examples of things namespaced under these schemas:
+    - Our TLD table 
+    - Functions
+    - Sequences
+- Options for setting up `PUBLIC` access:
+    - Get rid of everything and recreate after setting up default permissions.
+        - This is part of the long term upgrade strategy, with some caveats.
+    - Go through and do permissions on a per-object basis.
+    - Figure out how to upgrade SQL functions.
+- Getting rid of everything is a problem because we store e.g. record summaries / expressions / templates here.
+    - We need a strategy for how to drop things and what to use `CASCADE` for.
+- Can we get away with doing it on a per object basis for now?
+    - We don't have many tables
+    - Postgres automatically grants usage on types and execute on function - this covers a majority of what we have currently.
+    - We can just do it manually for now.
+- Idea: could we have `PUBLIC` be the owner?
+    - `PUBLIC` is not a true role, not sure if this would work.
+    - We'd need to think through how that would work with upgrades.
+    - Upgrades need the same role as original installation, that's a requirement, we're okay with that.
+
+### Installation plan outcomes
+
+**For "RC"**
+
+- Update documentation
+    - UI documentation (Ghislaine)
+    - Installation document (fixing inaccurate - whoever's free on the engineering team)
+- Testing install (Anish)
+- Double check `PUBLIC` permissions for usage on types and execute on function will work (Brent)
+- individually update permissions on tables and usage on schemas for `PUBLIC` (Brent to create an issue)
+
+**For Beta**
+
+- audit documentation for minimal permission usage
+    - also explain that what Mathesar is installed with isn't what Mathesar uses day to day
+- Consider migration / upgrade path from alpha or beta
+- Consider onboarding UI changes
+- `PUBLIC` permissions / ownership - full implementation