Rsgraber/task 1344 log deletes #5421
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
### 📣 Summary Improve multiple pinned columns handling. Allow pinning columns to right side. Improve pinned column styling based on table having horizontal scrollbar. Add reusable `useViewportSize` and `useWindowEvent` hooks. Add extensive story for testing the component, including left/right column pinning, the amount of columns and much more. ### 💭 Notes Both `useViewportSize` and `useWindowEvent` hooks were copied from `@mantine/hooks`, retaining the original code as closely as possible. We most possibly will use Mantine in near future, and we should replace both with the ones from Mantine package. Pinned columns have visual shadow to distinct them from other columns (useful when scrolling table horizontally). That shadow is not being added if table has no horizontal scrollbar. @magicznyleszek this should be used in actions column added in #5309 (should be always pinned to right) ### 👀 Preview steps Best way to test component changes: 1. run storybook locally 2. go to http://localhost:6006/?path=/docs/misc-universaltable--docs 3. 🟢 verify columns pinning works for all possible combinations - story allows pinning one or two columns on both sides 4. 🟢 verify pinned columns have shadow only if table has lots of columns (i.e. if there is horizontal scrollbar) 5. 🟢 verify all the other props of component work as expected Verify that Organization Members table still works: 1. ℹ️ have multiple different users 2. for one of the users (e.g. "joe"), use http://kf.kobo.local/admin/organizations/organization/ to add multiple users into joe's organization 3. for one of the users (e.g. "sue") set the role to "admin" 4. enable "Multi-members override" for joe's organization 5. enable feature flag `mmosEnabled` 7. navigate to `#/account/organization/members` (as "joe") 8. 🟢 notice that the table works as previously 👌 Verify that Recent Project Activity table still works: 1. note: this particular table displays mock data right now 2. for a deployed project go to `#/forms/<uid>/settings/activity` 3. 🟢 notice that the table works as previously 👌 --------- Co-authored-by: RuthShryock <[email protected]>
### 💭 Notes Followup change after TASK-1312 was done.
### 💭 Notes This PR fetches data from the backend: - Some modifications in the `PaginatedQueryUniversalTable` were needed to accommodate passing extra data for the query, that affected existent queries. I tried making it a minimal impact though. - Filter selector and export button actions will be finished in a future task ### 👀 Preview steps 1. ℹ️ have account and a project 2. Have the activity logs feature flag on with: `?ff_activityLogsEnabled=true` 3. Make some changes to the project, like editing the form and redeploying 4. Navigate to Project > Settings > Activity 5. 🟢 Changes made to the project should appear in the list
…y TASK-1357 (#5345) ### 🗒️ Checklist 1. [x] run linter locally 2. [x] update all related docs (API, README, inline, etc.), if any 3. [x] draft PR with a title `<type>(<scope>)<!>: <title> TASK-1234` 4. [x] tag PR: at least `frontend` or `backend` unless it's global 5. [x] fill in the template below and delete template comments 6. [x] review thyself: read the diff and repro the preview as written 7. [x] open PR & confirm that CI passes 8. [ ] request reviewers, if needed 9. [ ] delete this section before merging ### 📣 Summary After migrating `useOrganizationQuery` to use the `useSession` hook, we still have some direct references to `sessionStore`. This PR removes `sessionStore` from `useOrganizationQuery` entirely. ### 👀 Preview steps This PR should not change app behavior 1. Login as an MMO admin or owner 2. Load the organization settings and members pages 3. Observe no difference in displayed data or API calls between this branch and `main`
…-1359 (#5347) ### 🗒️ Checklist 1. [x] run linter locally 2. [x] update all related docs (API, README, inline, etc.), if any 3. [x] draft PR with a title `<type>(<scope>)<!>: <title> TASK-1234` 4. [x] tag PR: at least `frontend` or `backend` unless it's global 5. [x] fill in the template below and delete template comments 6. [x] review thyself: read the diff and repro the preview as written 7. [x] open PR & confirm that CI passes 8. [x] request reviewers, if needed 9. [ ] delete this section before merging ### 💭 Notes This PR hides the `Export all data` button behind a feature flag, to be viewed and tested conditionally. The final implementation of the button will be worked on a future PR, for another project. ### 👀 Preview steps 1. ℹ️ have account and a project 2. Have the activity logs feature flag on with: ?ff_activityLogsEnabled=true 3. Make some changes to the project, like editing the form and redeploying 4. Navigate to Project > Settings > Activity 5. 🟢 `Export all data` should not be visible 6. Enable the button feature flag with: ?ff_exportActivityLogsEnabled=true 7. 🟢 `Export all data` should be visible 8. Button behavior is mocked so far and won't have any effect right now
…5346) ### 🗒️ Checklist 1. [x] run linter locally 2. [x] update all related docs (API, README, inline, etc.), if any 3. [x] draft PR with a title `<type>(<scope>)<!>: <title> TASK-1234` 4. [x] tag PR: at least `frontend` or `backend` unless it's global 5. [x] fill in the template below and delete template comments 6. [x] review thyself: read the diff and repro the preview as written 7. [x] open PR & confirm that CI passes 8. [x] request reviewers, if needed 9. [x] delete this section before merging ### 📣 Summary Avoid unnecessary fetches of organization data ### 📖 Description After patching changes to organization members react-query was making two (sometimes one) refetches of backend data for `useOrganizationQuery`. This was undesired behavior. We want the organization members list to be refetched, but not the organization detail itself. To resolve this, I have set the `staleTime` option on `useOrganizationQuery` to 2 minutes. Since the data will not be considered stale until 2 minutes passes since the last refresh, these unnecessary API calls will not be made. Additionally, we have added an optional param to the Organization query to invalidate cached data on mount. This is used by the settings page. Since this page is intended for editing organization data, I think it is preferable to always fetch the latest data when opening it. ### 👀 Preview steps 1. Sign in as an MMO admin or owner for an org with a few members 2. On the organization members table, change the role of one of the other members 3. On main, observe the organization data being fetched after a successful member patch request 4. On this branch, observe no org data fetch 5. On this branch, navigate to the Organization settings page and see that the organization data is refetched. ### 💭 Notes I set a very low stale time for the organization. There had been some discussion about setting a long staleTime, but my thinking here is that our real goal with this change is to prevent the frontend from spamming the backend with requests for organization data on every member mutation. A low staleTime achieves this while still allowing for fairly frequent automatic updates of the data. --------- Co-authored-by: Paulo Amorim <[email protected]>
### 📣 Summary Fix error that was causing infinite loading spinner on usage page for non-Stripe instances. ### 📖 Description The usage page was expecting addons context to complete loading before switching from loading spinner to displaying page contents. However, the usage page needs to be usable on non-Stripe instances addons context never loads on such instances. I have adjusted the logic for checking whether or not the page is ready to display accordingly. At the same time, I also removed the memoization for this logic, as it was unnecessary and only used in one place. ### 👀 Preview steps 1. Access the usage page with Stripe disabled 2. On main, you will get an infinite loading spinner 3. On this branch, you will see the usage page as expected Co-authored-by: Anji Tong <[email protected]>
…s and texts TASK-1371 (#5354) ### 📣 Summary This PR adds labels to all action items and display the new labels in the filter selection. Also, all the existing items and texts were reviewed and updated based on [the actions list](https://www.notion.so/kobotoolbox/Write-code-for-rendering-all-possible-activity-messages-in-the-UI-1287e515f65480868bbcdc19c085920f?pvs=4#1287e515f654808a83cce66d13abde6c) ### 📖 Description - A new label property was added to all items in the `AUDIT_ACTION_TYPES` - This new property is now being used as the label for the filter selection items - The filter selection box was enlarged from 150px to 280px (initially suggested new size was of 250px, but it was needed to make it even larger to fit all the existing labels) - All the items from `AuditActions` enum and all the texts from `AUDIT_ACTION_TYPES` were reviewed and updated based on [the actions list](https://www.notion.so/kobotoolbox/Write-code-for-rendering-all-possible-activity-messages-in-the-UI-1287e515f65480868bbcdc19c085920f?pvs=4#1287e515f654808a83cce66d13abde6c) - Transferring a project and modifying permissions are special cases where more than 1 username is used in the message. A fix for that with the current metadata was added. ### 👀 Preview steps 1. ℹ️ have an account and a project 2. Have the activity logs feature flag on with: `?ff_activityLogsEnabled=true` 3. Transfer a project to another user 4. Navigate to the project's Settings > Activity 5. 🟢 The transfer should be displayed in the activity log 6. 🟢 The destination username should be properly displayed 7. Change the access permission of an user 8. 🟢 The permission change should be displayed in the activity log 9. 🟢 The username who had the permission changes should be displayed in the log 10. All other logged actions should be displayed in the list with the proper text
### 📣 Summary Correct the list of available actions in the API documentation for project history logs.
### 📣 Summary Fix typos and formatting in the audit log endpoint documentation ### 📖 Description old:  new: 
This fixes the unwanted cropping of the plan selection dropdown in addons view ### 💭 Notes There was an `overflow-y: auto` style in the dropdown's container class that was forcing the crop of the list.
### 📣 Summary Open `MemberRoleSelector` up and `MemberActionsDropdown` on the left - to avoid both of them opening partially outside the container (and causing an unnecessary scrollbar). ### 👀 Preview steps 1. ℹ️ have an organization with multiple members 2. log in as user having either "owner" or "admin" role 3. go to `#/account/organization/members` 4. 🔴 [on main] notice that `MemberRoleSelector` for last row opens outside visible area causing scrollbar to happen 5. 🔴 [on main] notice that `MemberActionsDropdown` for last row opens outside visible area causing scrollbar to happen 6. 🟢 [on PR] notice that both of the issues no longer happen, as both of the components are opening in different placements
…ermissions TASK-1366 (#5351) ### 📣 Summary Fixed an issue where users with partial permissions could no longer edit submissions they were allowed to. ### 📖 Description Users with partial permissions faced an issue where they were unable to edit submissions they had proper access to. This fix resolves the problem, allowing these users to edit submissions within their permissions scope, while maintaining the integrity of restricted resources.
#5357) ### 📣 Summary Added validation to block the creation of invites for already existing transfers. ### 📖 Description This update prevents the creation of duplicate invites when a transfer for the same resource already exists. By avoiding redundant invites, the system ensures better consistency and prevents confusion or potential conflicts arising from simultaneous transfers.
…#5326) ### 📣 Summary Update asset and service usage code to return only a single set of data for the current billing cycle, regardless of whether that cycle is monthly or yearly and adjust frontend accordingly. ### 📖 Description Currently, the `ServiceUsageSerializer` and `AssetUsageSerializer` return usage information calculated according to a monthly billing cycle and a yearly billing cycle, regardless of what kind of billing cycle a user is actually subscribed to. So if a user is on a monthly plan, we make up a hypothetical yearly cycle and return data for that in addition to the actual monthly cycle they are on. The frontend, in turn, selects the correct cycle information to display based on a separate request fetching the user’s subscription information. The hypothetical cycle is never displayed and doesn’t seem to be used for anything at all. This PR merges the functionality of the `get_monthly_billing_dates()` and `get_yearly_billing_dates()` utils into a single function that, once it determines which cycle an account is on, returns the relevant `period_start` and `period_end` dates. ### 👀 Preview steps For frontend preview: 1. Create a new user on a Stripe-enabled instance 2. Navigate to usage page. Observe that user is on community plan with start date corresponding to account creation date. Displayed usage period should correspond to either first day of this month or last day of previous month (most likely the latter, though it currently depends on one’s timezone) and the last day of this month. 3. Purchase a monthly plan and sync djstripe Subscriptions, navigate to usage page. Observe that start date is still account creation date. Displayed usage period should now correspond to start date and one month after start date. 4. Cancel plan as the user, then cancel the plan via Stripe (or ask someone to do this), and sync subscriptions. Visit usage page and observe dates have not changed (because your community plan dates now correspond to date of cancellation and one month later). 5. Sign up for a yearly plan and sync subscriptions. Visit usage page and observe that start date remains the same, while displayed usage period ends a year from today.
### 📣 Summary Filter option for activity list are now sorted by a pre-defined relevance order ### 📖 Description - An `order` property was added to the `AUDIT_ACTION` objects - Order was set for the actions based on [this table](https://www.notion.so/kobotoolbox/Write-code-for-rendering-all-possible-activity-messages-in-the-UI-1287e515f65480868bbcdc19c085920f?pvs=4#1287e515f654808a83cce66d13abde6c) - Actions were sorted based on the `order` property ### 👀 Preview steps <!-- Delete this section if behavior can't change. --> <!-- If behavior changes or merely may change, add a preview of a minimal happy path. --> Bug template: 1. ℹ️ have an account and a project 2. Have the activity logs feature flag on with: `?ff_activityLogsEnabled=true` 4. Navigate to Project > Settings > Activity 5. Open the `Filter by` select box 6. 🟢 Notice that the items are sorted according to [this table](https://www.notion.so/kobotoolbox/Write-code-for-rendering-all-possible-activity-messages-in-the-UI-1287e515f65480868bbcdc19c085920f?pvs=4#1287e515f654808a83cce66d13abde6c)
### 📣 Summary Fixes a 500 being thrown when a non-superuser goes to /admin and then tries to log in as a superuser. ### 👷 Description for instance maintainers Upgrade django-allauth to 65.1.0. ### 💭 Notes The simplest solution seemed to be just to upgrade django-allauth. It's unclear which exact commit fixes the bug and we are very behind in versions so upgraded to the latest. Nothing obvious broke except one unit test. ### 👀 Preview steps Bug template: 1. ℹ️ Have 2 accounts, one super and one not 2. Log in as the non-superuser 3. Go to /admin 4. You should be redirected to the login page. 5. Log in as the super user 6. 🔴 [on main] 500 error 7. Checkout the PR branch. Make sure to reinstall requirements. 8. Do 1-5 again. 9. 🟢 [on PR] You should be correctly logged in and sent to the admin page
…K-1334 (#5353) ### 📣 Summary Enable filtering of assets by organization and owner names and ensure these fields are updated during organization changes and project ownership transfers.
Fixes a 500 being thrown when a non-superuser goes to /admin and then tries to log in as a superuser. Upgrade django-allauth to 65.1.0. The simplest solution seemed to be just to upgrade django-allauth. It's unclear which exact commit fixes the bug and we are very behind in versions so upgraded to the latest. Nothing obvious broke except one unit test. Bug template: 1. ℹ️ Have 2 accounts, one super and one not 2. Log in as the non-superuser 3. Go to /admin 4. You should be redirected to the login page. 5. Log in as the super user 6. 🔴 [on main] 500 error 7. Checkout the PR branch. Make sure to reinstall requirements. 8. Do 1-5 again. 9. 🟢 [on PR] You should be correctly logged in and sent to the admin page
…onized when transferring project ownership TASK-1352 (#5365) ### 📣 Summary Fixed an issue where OpenRosa media files were not synced during project ownership transfers causing a 404 error in Collect when opening a project due to missing media files. ### 📖 Description An issue was resolved where OpenRosa media files were not properly synced when transferring project ownership. This fix ensures that all media files are transferred correctly along with the project, preventing errors and maintaining data consistency. Previously, the absence of these media files resulted in a 404 error when users attempted to open the project using Collect. This update addresses the root cause, ensuring that all required files are available post-transfer.
### 📣 Summary Updates backend code to check Stripe products for default "community plan" limits when determining organization usage. ### 📖 Description Currently, the frontend gets billing usage limits for the free Community Plan from the corresponding Stripe product (returned by the products endpoint). The backend, however, does not reference these limits at all. This has not been a problem previously, because the backend currently does not enforce usage limits (only NLP limits are enforced, and this is handled by the frontend at present) and had no other need for these limits. Now that the backend is tracking addon usage, however, it does need to be aware of community plan usage limits. This PR updates the get_organization_plan_limit util function to use the limits from the metadata of the default community plan when an organization does not have a subscription. ### 👀 Preview steps Change covered by unit test
…t TASK-1340 (#5368) ### 💭 Notes Internal changes only ### Preview steps 1. ℹ️ have account and a project 2. add submissions 4. 🟢 Make sure you can still see submissions in Project > Data
…5378) ### 📣 Summary Adds query param to asset API request on `myOrgProjectsRoute` to restrict query to only surveys. ### 👀 Preview steps 1. Create an MMO and a collection 2. View MMO org project list 3. On main, the collection will appear on this list 4. On this branch, the collection will not appear (because a query param is added to the API request)
Change which commits we compare in darker.yml, not to include changes introduced by other branches More details: - #5311 - #5282 (comment)
#5379) ### 📣 Summary Added a new system for handling long-running migrations using Celery. ### 📖 Description A new long-running migration system has been implemented, leveraging Celery to process migrations in the background. This system is designed to handle large-scale data updates that would otherwise cause require significant downtime with regular Django migrations ### 💭 Notes This long-running migration system leverages Celery for asynchronous task processing. However, a similar (and likely more robust) feature is being developed in Django, as detailed in [DEP 14 - Background Workers](https://github.com/django/deps/blob/main/accepted/0014-background-workers.rst). Once Django officially releases its built-in background worker system, this custom solution will be phased out in favor of the native implementation to better align with the Django ecosystem.
### 📣 Summary Fixed an issue with incorrect crontab syntax in the Celery Beat scheduler. ### 📖 Description An issue with the crontab syntax in the Celery Beat scheduler prevented periodic tasks from running correctly. This fix updates the syntax to conform to the expected format.
…#5364) ### 🗒️ Checklist 1. [x] run linter locally 2. [x] update all related docs (API, README, inline, etc.), if any 3. [x] draft PR with a title `<type>(<scope>)<!>: <title> TASK-1234` 4. [x] tag PR: at least `frontend` or `backend` unless it's global 5. [x] fill in the template below and delete template comments 6. [x] review thyself: read the diff and repro the preview as written 7. [x] open PR & confirm that CI passes 8. [x] request reviewers, if needed 9. [ ] delete this section before merging ### 📣 Summary Activity logs is no longer hidden behind a feature flag and i snow accessible via Project > Settings > Activity ### 📖 Description - The feature flag was removed from the enum - The link to the route is now always visible ### 👀 Preview steps 1. ℹ️ have an account and a project 2. Remove or disable the activity logs feature flag on with: `?ff_activityLogsEnabled=false` if needed 4. Navigate to Project > Settings 5. 🟢 The `Activity` session should be accessible
…s TASK-1393 (#5384) ### 📣 Summary Fixes viewswitcher so only MMO admins and owners see option for `myOrgProjectsRoute` and restricts route itself based on user's org role. ### 👀 Preview steps 1. Create/use an MMO with at least three members: owner, admin and member 2. Login as each member and view projects list. 3. Observe that project list view switcher only gives "my org projects" option for admin and owner 4. Observe that member is redirected to normal project route when trying to navigate to org project route directly via URL
### 📣 Summary Now the Organizations feature implemented up to this point is no longer hidden behind a feature flag ### 📖 Description - `isMMosEnabled` feature flag was removed - routes and menus hidden behind it are now enabled by default - organizationQuery no longer returns fixed result for `is_mmo` ### 👀 Preview steps Feature/no-change template: 1. ℹ️ have account 2. ℹ️ have or be part of an organization 3. ℹ️ Make sure to disable the active feature flag with `?ff_isMMosEnabled=false` or cleaning your session storage 4. Navigate to account settings 5. 🟢 notice that the organization links are visible 6. 🟢 notice that you can navigate and operate organization feature freely without the feature flag
…296 (#5399) ### 📣 Summary Type selector for export now reflects the actual last export settings fetched from history ### 📖 Description - The export type selection box was not being updated on component mount when the last exported setting is loaded - That was causing the silent selection of the export type fetched without updating the actual selection box - This way, if the first export of the project was a CSV, then after fetching this export setting the type selection box would still be displaying XLS as the default selected, even though the actual selection in the state was changed to CSV. - The component is displaying the information from the store, and not from state - I added an update to the type in the exportStore when applying the fetched export settings to the state, so it displays the actual selection. ### 👀 Preview steps <!-- Delete this section if behavior can't change. --> <!-- If behavior changes or merely may change, add a preview of a minimal happy path. --> Bug template: 1. ℹ️ have an account and a deployed project with no exports 2. navigate to project > data > downloads 3. select the CSV (or any other than XSL) type to export 4. export the project data 5. leave the Downloads view (by clicking on Gallery, for example) 6. Go back to Downloads view 8. 🔴 [on main] notice that XSL appears as the selected type, even though it's not. You can check Network tab or just click export to see it exporting in the actual selected type 9. 🟢 [on PR] notice that the selection box updated to reflect the actual selected type
) ### 🗒️ Checklist 1. [x] run linter locally 2. [x] update all related docs (API, README, inline, etc.), if any 3. [x] draft PR with a title `<type>(<scope>)<!>: <title> TASK-1234` 4. [x] tag PR: at least `frontend` or `backend` unless it's global 5. [x] fill in the template below and delete template comments 6. [x] review thyself: read the diff and repro the preview as written 7. [x] open PR & confirm that CI passes 8. [x] request reviewers, if needed 9. [x] delete this section before merging ### 📣 Summary <!-- Delete this section if changes are internal only. --> <!-- One sentence summary for the public changelog, worded for non-technical seasoned Kobo users. --> Fixes an issue where a form will not deploy if it fails one time already. ### 📖 Description <!-- Delete this section if summary already said everything. --> <!-- Full description for the public changelog, worded for non-technical seasoned Kobo users. --> Connecting to openrosa needed to be wrapped in an atomic transaction. ### 👀 Preview steps <!-- Delete this section if behavior can't change. --> <!-- If behavior changes or merely may change, add a preview of a minimal happy path. --> Feature/no-change template: 1. ℹ️ have account and a new project 2. make the project fail to deploy (add `1/0` inside `connect()` in `openrosa_backend.py` 3. deploy the form (it fails) 4. remove the `1/0` 5. deploy form again (should deploy normally) See https://www.notion.so/kobotoolbox/Library-locked-form-cannot-be-deployed-1527e515f654806ab4f9c4d42a59ac52
### 🗒️ Checklist 1. [x] run linter locally 2. [x] update all related docs (API, README, inline, etc.), if any 3. [x] draft PR with a title `<type>(<scope>)<!>: <title> TASK-1234` 4. [x] tag PR: at least `frontend` or `backend` unless it's global 5. [x] fill in the template below and delete template comments 6. [x] review thyself: read the diff and repro the preview as written 7. [x] open PR & confirm that CI passes 8. [ ] request reviewers, if needed 9. [ ] delete this section before merging ### 📣 Summary This fixes an incorrect error message ### 📖 Description Fixed text for error message
…#5401) ### 📣 Summary The filter options for activity logs now only display the existing options for the project ### 📖 Description - Instead of using a hardcoded list of actions to display the filter data, now we're fetching the available action list from the API. - The returned actions are still translated and sorted in the frontend ### 👀 Preview steps 1. ℹ️ have account and a project 2. ℹ️ have activity to be logged in the project 3. navigate to project settings > activities 4. 🟢 notice that in the filter selection box only the existing-in-project activity actions are available for filtering --------- Co-authored-by: rgraber <[email protected]>
### 🗒️ Checklist 1. [x] run linter locally 2. [x] update all related docs (API, README, inline, etc.), if any 3. [x] draft PR with a title `<type>(<scope>)<!>: <title> TASK-1234` 4. [x] tag PR: at least `frontend` or `backend` unless it's global 5. [x] fill in the template below and delete template comments 6. [x] review thyself: read the diff and repro the preview as written 7. [x] open PR & confirm that CI passes 8. [x] request reviewers, if needed 9. [x] delete this section before merging ### 📣 Summary <!-- Delete this section if changes are internal only. --> <!-- One sentence summary for the public changelog, worded for non-technical seasoned Kobo users. --> Line in transferring ownership email for MMOs is no longer relevant and is removed. ### 👀 Preview steps <!-- Delete this section if behavior can't change. --> <!-- If behavior changes or merely may change, add a preview of a minimal happy path. --> 1. Have 2 accounts and emails enabled 3. User A is in an MMO, user B is not 4. Transfer project from user B to user A 5. Email should be sent without the removed line
### 📣 Summary Internal addition: add missing `fetchPatchUrl`, `fetchPutUrl`, and `fetchDeleteUrl` to `api.ts`.
Fix the error handling for invalid survey JSON content when deploying ### 📖 Description This PR adds error handling for the case when Pyxform fails when attempting to deploy a survey with invalid content. A unit test was included to ensure this works ok. ### 👀 Preview steps 1. Create a new survey using a bad xls form (see the notion page for a test file with bad format) 2. Attempt to deploy the form 3. The frontend should show a validation error with a hint of how to fix it 4. Edit and save the form (labels are added automatically when you enter the form editor, so there's no need to do anything in this case, just edit and hit the save button) 5. Attempt to deploy again 6. It should be deployed without issues
### 💭 Notes Migrating files to TS introduced some non-trivial changes, like: - `enum` introduction required some parts of the code to be rewritten (more `if`'s etc.) - mocks file had to be rewritten from scratch, as the asset responses there were extremely outdated and incomplete ### 👀 Preview steps There is a nice long [Library Locking Technical Reference article](https://kobotoolbox.github.io/articles/library-locking-technical-reference) that I feel would be very helpful here :) Some useful templates for testing: - [locking template 1 (lock_all).xls](https://github.com/user-attachments/files/18306729/locking.template.1.lock_all.xls) - [locking template 2 (profile, language_edit).xls](https://github.com/user-attachments/files/18306730/locking.template.2.profile.language_edit.xls) - [locking template 3 (profile).xlsx](https://github.com/user-attachments/files/18306731/locking.template.3.profile.xlsx) Testing: 1. Upload one of the above templates (__no drag&drop!__) using "My Library" > "NEW" > "Upload file" with "Upload as template" checked (__important!__ as without this, all locking features would be stripped by BE code). 6. Open the template in Form Builder 7. 🟢 notice that locking features work as expected (see Technical Reference linked above) 8. Go to "My Library". 9. For the locked template in the list use "Create project" button. 10. Open the newly created project in Form Builder. 11. 🟢 notice that locking features work as expected There are three __fixes__ in this PR (_mea culpa_ for not splitting). __First fix__: I changed how `isAssetLockable` works, by extending it to also include `template`s (previously only allowed `survey`s). This function works like a feature flag -ish, and I've noticed that with a template that is fully locked (has `lock_all: true`), the Form Builder sidebar wasn't all disabled. __Second fix__: in the same area as above, Background audio setting was not being disabled, and it should be with `lock_all`. I suspect we've added locking before adding Background audio in there and forgot to include it. __Third fix__: I no longer disabled "Add from Library" and "Layout & Settings" buttons for `lock_all` forms. There is an annoying tiny UX bug that was happening with current code: 1. Open a non-locked form in Form Builder and open "Layout & Settings" sidebar 2. The sidebar being opened is being remembered by FE code 3. Open a locked form in Form Builder and notice the sidebar is open 4. 🔴 Notice you can't close the sidebar, because the toggle button is disabled 5. 🟢 Notice that with this PR it is now possible to close sidebar (and everything inside the sideabar is already disabled, so no harm if user opens it) --------- Co-authored-by: Kalvis Kalniņš <[email protected]>
…he correct database (#5413) Fixes a 500 error when attempting to create an account on certain servers, e.g. the Global KoboToolbox instance (kf.kobotoolbox.org). This is a critical fix, so please excuse the terseness of this description.
…he correct database (#5413) Fixes a 500 error when attempting to create an account on certain servers, e.g. the Global KoboToolbox instance (kf.kobotoolbox.org). This is a critical fix, so please excuse the terseness of this description.
### 📣 Summary Log updates to submissions, both content and validation status. ### 💭 Notes #### SubmissionUpdate The `SubmissionUpdate` class is just a dataclass meant to make it clear what information we need to create a PH log for submission modification/creation/deletion. It's meant mostly to help future developers since we're not using the usual `initial_data`/`updated_data` pattern where we just take configured fields off of a model. #### ProjectHistoryLog.__init__ This PR includes a small refactor on ProjectHistoryLog to set the `app_name`, `model_name`, and `log_type` in the `__init__` method like we do with `create`. This saves us some repeated code when we are creating logs in bulk. #### Attaching the asset to the request We always need the `asset_uid` when logging any views that include the `AssetNestedObjectViewsetMixin` mixin, so I updated `AuditLoggedViewSet` to always attach the asset (available via the mixin) to the request. We may be able to use this to simplify other code later if we wish. #### Where we add data to the request We can't use the usual method of having the views inherit from `AuditLoggedViewSet` and configuring `logged_fields` on the relevant model because the viewsets that update Instances rarely act directly on the Instance objects via get_object or the serializers. Instead they usually have custom code that works through the deployment object on the asset. We could pass the request from the viewset through the layers of other methods until we get to the part where we are actually updating instances, but this would require a lot of changes in existing view code and we're trying to keep the audit log code relatively self-contained. Changes to logging code should ideally not require changes in view code. Instead, I decided to use a receiver on the Instance model `post_save` signal. This also should allow the code to be more backend-agnostic since we did not update anything directly in the OpenRosaDeploymentBackend model, where most of the actual updating takes place. Theoretically, any backend would have to eventually update the Instance model with the new `xml` and `status` fields, regardless of how else it went about performing the updates. This is an assumption we have to make since we don't have any other "real" backend implementations, but it seems a safe one. The exception to this is when updating multiple validations statuses, because that is done with a bulk update, which doesn't send the `post_save` signal. In that bit of code, we have to manually attach the updated instances to the request. It's not considered great practice to get the request as part of model code but the alternative once again requires a significant refactor to pass the request through multiple layers. ### 👀 Preview steps Feature/no-change template: 1. Regression test: follow the test plan at #5387 to make sure that logging for duplicate submissions still works since that changed. 1. ℹ️ have at least 2 accounts and a project. Make sure both accounts have permission to add submissions to the project. For this preview, assume user1 owns the project. 2. Add a submission as the owner 3. Log in as user2 and add a submission. You may want to do this in a separate private tab, otherwise sometimes the enketo login stays cached and the submissions end up attached to the first user. 4. Login as user1 again and enable submissions without username or email 5. Add one more submission. It should come in as anonymous (ie no _submitted_by) 6. Go to the My Project > Data. 7. Change the validation status of a user1's submission to 'On Hold' using the dropdown in the table. 8. Go to `/api/v2/assets/<asset_uid>/history` 9. 🟢 There should be a new project history log with `action="modify-submission"` and the usual metadata, plus ``` "submission": { "status": "On Hold", "submitted_by": "user1" } ``` 10. Go back to the table and select all 3 submissions. 11. Select 'Change status' and update the status to 'Approved' for all of them 12. 🟢 Reload the endpoint. There should be 3 new logs with `action="modify-submission"` and the usual metadata, plus ``` "submission": { "status": "Approved", "submitted_by": "user1/user2/AnonymousUser" } ``` Note: there should be one log each for the different users since they each have one submission 13. Go back to the table and click the pencil by user2's submission. Edit an answer to a question. 14. 🟢 Reload the endpoint. There should be a new log with `action="modify-submission"` and the usual metadata, plus ``` "submission": { "submitted_by": "user2" } ``` Note there is no validation status since that did not change. 15. Go back to the table and select all submissions. 16. Hit `Edit` and edit the answer to a question 17. 🟢 Reload the endpoint. There should be a 3 new logs with `action="modify-submission"` and the usual metadata, plus ``` "submission": { "submitted_by": "user1/user2/AnonymousUser" } ```
### 📣 Summary The navigation and data flow is improved when an MMO organization admin removes itself from the organization. ### 📖 Description The objective of this PR is to: - Minimize wrong API calls due to permissions and session data that needs to be updated - Present a better flow for the user, redirecting them to the correct view after the removal There's still a big margin for improving, mainly due to some work needed in `useUsage`, but it unfolds into several other files and flows, so it's better to be handled in a separated PR ### 👀 Preview steps 1. ℹ️ have an account and a project 2. Be the admin in an MMO 3. Navigate to Account Settings > Members 4. Remove yourself from the organization 5. 🔴 [on main] notice that the user is not redirected and there are some failed attempts to API calls due to permissions 6. 🟢 [on PR] notice that the user is redirected and there's only 1 failed attempt to usage API
### 💭 Notes Developer-facing changes only. Changes the username of the admin user to `adminuser` in preparation for disallowing the name `admin` as part of https://www.notion.so/kobotoolbox/Anonymous-submissions-dont-work-if-user-named-admin-owns-asset-1767e515f65480608dfcee76ba9b3710
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🗒️ Checklist
<type>(<scope>)<!>: <title> TASK-1234frontendorbackendunless it's global📣 Summary
📖 Description
👷 Description for instance maintainers
💭 Notes
👀 Preview steps
Bug template:
Feature/no-change template: