Which minor backend fixes to do during upcoming cycle?

[Dominykas Mostauskis]

I picked out some of the more recent backend tickets that aren't assigned and might fit within 4 weeks (individually). I then ordered them according to my perception of priority, with higher in the list (having lower index) meaning higher priority:

1. Demo users should only see their own database #2983 Unable to load Preview of the table on importing data from csv file in demo mode #2793
2. Remove the lazydict dependency #2960
3. Add support for citext column type #2959
4. JSON string is castable to URI #2941
5. StatementError when using the Record Selector to search by a partially-entered UUID #2724
6. Consider merging config into mathesar package #2712
7. Fix API handling of multi-column UNIQUE and PK columns #2245
8. Exploration Inconsistency when Corresponding Table is Deleted #2747
9. Temporary DataFile object is not deleted once the Table has been created #2910
10. API for connecting a new Database to Mathesar #2732

Instead of making a project out of a small set of issues that will take approximately 4 weeks to do, I propose agreeing upon a priority for these issues and making a project out of doing as many of them as possible during the 4 weeks and then cutting off whatever is left undone. Seems more flexible than trying to stick to a prediction of progress. Does this make sense?

Do you have issues to add to the queue? What priority would you give them? Would you change the priority I gave the above issues?

PS: I wish Gmail had Github integration so I wouldn't have to create readable links to issues manually.

[Sean Colsen]

This is tangential, but I wanted to briefly respond to your PS

create readable links to issues manually

For this, I use a combination of:

• copy-selection-as-markdown - a Firefox add-on that makes it really easy to copy the URL of a page as a markdown URL. I also have these “title substitution” regexes in my advanced settings for that add-on, which makes the titles a little cleaner when copying from GitHub or the wiki

  / by \S+ · Pull Request #\d+ · \S+$/
  / · Issue #\d+ · \S+$/
  /\s*\| Mathesar Wiki\s*$/
  

• markdown-here-revival - a Thunderbird add-on that makes it really easy to convert markdown into formatted HTML emails.

You may notice that I almost never paste raw URLs into communication — I pretty much always copy them using that add-on to make them readable. It’s super easy!

​

[Dominykas Mostauskis]

@Sean Colsen thanks! I'll try out a similar addon that can also copy directly as html. Here's a link to that addon copied with that addon: Copy URL To Clipboard – Get this Extension for 🦊 Firefox (en-US)

I can tell why you have custom rewriting rules...

[Dominykas Mostauskis]

@Sean Colsen here are the frontend+backend tasks ranked according to my sense of priority:

1. Exploration Inconsistency when Corresponding Table is Deleted · Issue #2747 · centerofci/mathesar
2. Allow users to add and remove primary key constraints · Issue #2686 · centerofci/mathesar
3. No tables visible when viewing an existing schema · Issue #2709 · centerofci/mathesar
4. Allow deleting a record with CASCADE · Issue #2202 · centerofci/mathesar
5. Improve handling of non-Mathesar JSON types · Issue #1324 · centerofci/mathesar
6. Keep `today` as `today` in column default value · Issue #2754 · centerofci/mathesar
7. Add context menu to set cell to default value · Issue #1361 · centerofci/mathesar
8. Incorporate field name into error messages when relevant · Issue #1370 · centerofci/mathesar
9. Make column type inference optional · Issue #2358 · centerofci/mathesar
10. Make column type inference per-column · Issue #2359 · centerofci/mathesar
11. Decouple column type inference from an HTTP transaction · Issue #2360 · centerofci/mathesar

This list doesn't overlap with my previous list (the previous list had only backend issues).

I'd say that the backend issues 1 and 2 from the previous list (they're on the same line, both under item 1, due to a formatting mishap) are more important than the most important frontend+backend issues. After backend issues 1 and 2 are done, I think the frontend+backend issues are more important.

So a final ranking could be something like this (limited to 7 issues, don't see a reason to create a detailed ranking of all of 20+ issues):

1. Demo users should only see their own database #2983

1. Unable to load Preview of the table on importing data from csv file in demo mode #2793 Exploration Inconsistency when Corresponding Table is Deleted · Issue #2747 · centerofci /mathesar 
2. Allow users to add and remove primary key constraints · Issue #2686 · centerofci/mathesar
3. No tables visible when viewing an existing schema · Issue #2709 · centerofci/mathesar
4. Allow deleting a record with CASCADE · Issue #2202 · centerofci /mathesar

1. JSON string is castable to URI #2941
   

1. Improve handling of non-Mathesar JSON types · Issue #1324 · centerofci /mathesar

1. StatementError when using the Record Selector to search by a partially-entered UUID #2724

[Kriti Godey]

Instead of making a project out of a small set of issues that will take approximately 4 weeks to do, I propose agreeing upon a priority for these issues and making a project out of doing as many of them as possible during the 4 weeks and then cutting off whatever is left undone. Seems more flexible than trying to stick to a prediction of progress.

I’m not sure about this. Part of the projects process is also about learning to scope appropriately for 4 week cycles. e.g. if we spent 4 weeks only solving one issue (even if it is the top priority issue), it would not be a good outcome for the cycle.

Priorities

I looked through the priorities lists and I think most of the full stack ones require product and design work and don't seem like low hanging fruit (e.g. Allow delenting a record with CASCADE will involve significant thought about how to communicate the list of objects the user is deleting, how/whether to handle multi-level CASCADEs etc.). I think it would be best to split this up into separate backend/frontend projects and limit the full-stack work.

Backend priorities

Here's a list based on what I think is important:

1. Remove the lazydict dependency #2960 - adds support for running Mathesar on more Python versions, which is important. We also already have a PR for this.
2. Add support for citext column type #2959 - user reported, blocks a real use case.
3. Does not work on windows #2961 – this is about removing a dependency

1. Demo users should only see their own database #2983

1. StatementError when using the Record Selector to search by a partially-entered UUID #2724

1. Fix API handling of multi-column UNIQUE and PK columns #2245

1. Incorporate field name into error messages when relevant · Issue #1370

1. Keep `today` as `today` in column default value · Issue #2754 (this one will involve some design work, so it's at the bottom)
   

This project should not include the following issues because they're related to Mukesh's installation work:

1. Consider merging config into mathesar package #2712

1. API for connecting a new Database to Mathesar #2732

Also Temporary DataFile object is not deleted once the Table has been created #2910 doesn't seem like a priority, it's not causing any issues that I know of.

Frontend priorities

Sean, you sent me these the other day, I assume these are still fine.

• Scroll sheet via touch
• Keep records in store while fetching
• Synchronize cell “active” and “focused” states
• Cell Context menu event should maintain the cell selection when triggered within the selection
• Re-focus table cell after opening record selector on that cell
• Autofocus on input element when a new column is supposed to be added
• Resolve UI confusion with two separate “Decimal Places” type options
• Use more intuitive labeling for Data Size in Integer in DB options
• Closing the context menu should not pass the click through
• Infinite loop when displaying software keyboard to edit cell on touch device
• Allow keyboard navigation within the breadcrumb selector
• Allow dragging to modify precedence of sorting conditions
• Allow deleting a record from its record page

---

Sean and Dom, any concerns with this? Does this give you enough information to write your projects up?

[Dominykas Mostauskis]

This is enough for me to write up a project.

If we'd like to do Add support for `citext` column type · Issue #2959 · centerofci/mathesar so as to close the related bug report, we also need to support the `point` location type. I've just created an issue for that. I'll consider supporting both of those types to have similar priority, unless someone objects.

[Kriti Godey]

I’ll consider supporting both of those types to have similar priority, unless someone objects.

Makes sense to me.

[Kriti Godey]

Please add https://github.com/centerofci/mathesar/issues/3013 to the list of high-priority issues, we had a user run into problems with it ).

[Kriti Godey]

Here's another high priority issue: https://github.com/centerofci/mathesar/issues/2995, it needs a little bit of design, but should be manageable.

[Dominykas Mostauskis]

Adding them to project. They will take most of the planned buffer time.