Show related projects (by lang code) in same org when creating project #979
Conversation
C# Unit Tests53 tests 53 ✅ 5s ⏱️ Results for commit d0a3040. ♻️ This comment has been updated with latest results. |
|
Pre-emptively rebasing on top of |
rmunn
force-pushed
the
feat/search-projects-in-org-by-lang-tag
branch
from
29e0632 to
f6fe512
Compare
|
With commit cecdcd1, we now deal with 2-letter codes in what I believe is the correct way: convert 3-letter codes to the equivalent 2-letter code (if there is an equivalent 2-letter code) before looking it up in the FLEx metadata. The LangTagsConstant file was produced by running the following jq '.[] | select((.tag | length) == 2) | {tag: .tag, iso639_3: .iso639_3}' < langtags.json > two-letter-tags.txtI then took the |
|
I just checked https://ldml.api.sil.org/langtags.json and found that my local copy was a little out of date, and in particular that it was missing one two-letter code added in the past couple of years. I pushed commit 3df5b3d to fix that, but that brings up an issue for discussion: how are we going to handle this in the future? Options include:
For myself, I'm inclined towards the first of these: keep a copy of langtags.json in our repo, and have a script that will check https://ldml.api.sil.org/langtags.json every so often and re-generate LangTagsConstants.cs if there is a newer version of langtags.json available on the server. (https://ldml.api.sil.org/langtags.json serves an ETag header, so we can use If-None-Match to avoid downloading a file that we already have; we'd just need to store the ETag value in |
|
Commit 159c1a2 is a start at a request-approval flow where project managers can approve a join request. It still needs a few things, which I'll work on tomorrow:
Perhaps I'll make the list of similar projects into a list of radio buttons, where the user can click on one and then click "Request to join" below. Then beside "Request to join" is "No, create project" which will dismiss the list of similar projects. (When the list is visible, the project description field and submit buttons are hidden, so you're forced to interact with the list of similar projects before you can click the submit button.) |
|
Marking as draft again, because the design we ended up with will want to use the mechanism from #986 to auto-fill in the invitation modal with user ID and name values from URL query params. So I want to put this on hold until #986 is merged, then build off of #986 for the frontend part of this. There's still more work that can be done on this PR while #986 isn't merged yet, so it's not blocked yet. At some point if #986 takes a long time to get merged, I'll mark this one as blocked and move on to something else. |
rmunn
force-pushed
the
feat/search-projects-in-org-by-lang-tag
branch
from
6539a7a to
1bb2662
Compare
If the org dropdown has a selected org, and there is a valid language code (2 or 3 characters), then a search will be made for any projects belonging to the selected org that have that language code in their list of currently active vernacular writing systems.
If someone types the language tag "eng", we want to search for "en" because that's how FLEx will have stored it as a writing system.
The langtags.json file I used initially was a couple years out of date, and there was one new 2-letter code assignment since then. Updating the LangTagConstants.cs file accordingly.
Could put it below the description instead, but we might want to save the user some typing in case they decide not to create the project after all, so we'll put the related projects list above the description so they'll see it before starting to type.
New GraphQL mutation allowing users to request joining any project in their org, which will send an email to project managers who can then approve the request. (Currently no email is sent to the user when their request is approved; we may add that later.)
This allows the frontend to show a success notification and redirect to the project page.
Instead of a new API endpoint in ProjectController, we'll just populate the AddProjectMember modal with the user's name and ID (once it acquires the ability to have a user ID), and then the flow will pass through the existing GraphQL mutations. That way we won't need to do any special work to update the GraphQL cache. It means one extra click for the admin to approve the project join request, but it also means that admins can choose to have the joining user join as a manager if they want, which will come in handy sometime.
Will eventually allow selecting one then clicking on a "request joining project" button below, or clicking a "No, I want a new project" button to get the description field and the submit button to become visible.
UI now requires either asking to join a related project, or clicking "No thanks, create a new project" in order to get access to the rest of the form including the submit button.
Also moved backend mutation back to using project ID now that it's easy
If the user clicks on the "Ask to join" button, they are trying to abandon the form so we don't want to ask them if they want to preserve the data previously entered.
If the "Ask to join" request failed for any reason, we don't want to navigate away from the form.
rmunn
force-pushed
the
feat/search-projects-in-org-by-lang-tag
branch
from
3485fc8 to
0c0fa9e
Compare
Also rename it to ProjectsInMyOrg since it's now a lot more generic.
Related search by name often turns up the same projects that the search by language code is turning up, so we'll ensure that we only add one copy of each project to the related-projects list.
frontend/src/routes/(authenticated)/project/create/+page.svelte
Outdated
Show resolved
Hide resolved
By simply creating a flattedNestedStore helper function with appropriate types, we can get rid of a lot of the unnecessary complexity we had ended up with in the related-projects stores.
frontend/src/routes/(authenticated)/project/create/+page.svelte
Outdated
Show resolved
Hide resolved
frontend/src/routes/(authenticated)/project/create/+page.svelte
Outdated
Show resolved
Hide resolved
frontend/src/routes/(authenticated)/project/create/+page.svelte
Outdated
Show resolved
Hide resolved
We don't need to use the queryStore functions here because there's no need to subscribe to store updates to catch values updated on the server. This allows us to get rid of the store-inside-a-store nesting and simplify the consuming code.
|
Closing and reopening to kick CodeQL into working right. |
Fixes #253.
Fixes #258.
When the user selects an org in the create-project page, any projects with similar names in that org are displayed in a list of possibly-related projects, and the user is invited to choose one of them to join instead of creating a new project. If he chooses to join the project, an email is sent to that project's manager(s) to ask them to approve it. Further down the create-project form, when a language code is entered, another GraphQL query is made searching for any projects with a vernacular writing system matching that language code, and those projects are added to the related-projects list. (Ordered first, above the related-by-name results, because they're more likely to be correct).
The related-projects list replaces the project description field and the submit button, so the user is forced to interact with it, either by clicking "Yes, join project" or by clicking "No thanks, create new project" before he can move on to creating the project. If he dismisses it by clicking "No thanks", he can still change his mind and see the list of related projects again. See demo below.
Work done:
E2E test to exercise the approval flowDecided to postpone E2E test to a later PRScreenshot of UI sketch:
Demo (note: location has moved since this recording was taken, now it's above the description):