feat: guest fixes added to missing save file fixes #377
Conversation
feat: 15.3.0
…ihub/SODA-for-SPARC into guest-contributor-fixes
…ihub/SODA-for-SPARC into guest-contributor-fixes
…ihub/SODA-for-SPARC into guest-contributor-fixes
…skip permissions page
|
Thank you for submitting this pull request! We appreciate your contribution to the project. Before we can merge it, we need to review the changes you've made to ensure they align with our code standards and meet the requirements of the project. We'll get back to you as soon as we can with feedback. Thanks again! |
Reviewer's Guide by SourceryThis PR implements fixes for guest user access and permissions in the guided curation workflow. The changes ensure proper handling of different user roles (guest, editor, viewer) and their corresponding access levels to various dataset features. Sequence diagram for checking user role and skipping pagessequenceDiagram
participant User
participant UI
participant API
participant Client
User->>UI: Navigate to a page
UI->>API: getDatasetRole(datasetName)
API-->>UI: role
alt role is editor
UI->>UI: Skip pages (permissions, banner, license)
else role is not editor
UI->>UI: Unskip pages (permissions, banner, license)
end
UI->>Client: Save progress
Client-->>UI: Progress saved
Class diagram for updated functions in guided-curate-dataset.jsclassDiagram
class GuidedCurateDataset {
+checkIfChangesMetadataPageShouldBeShown(pennsieveDatasetID)
+savePageChanges(pageBeingLeftID)
+openPage(targetPageID)
+guidedResumeProgress(datasetNameToResume)
+editPennsieveMetadata()
}
note for GuidedCurateDataset "New logic for handling guest and editor roles"
Class diagram for new function in globals.jsclassDiagram
class Globals {
+isWorkspaceGuest() bool
}
note for Globals "New function to check if user is a guest in the workspace"
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Thanks for making updates to your pull request. Our team will take a look and provide feedback as soon as possible. Please wait for any GitHub Actions to complete before editing your pull request. If you have any additional questions or concerns, feel free to let us know. Thank you for your contributions! |
|
Thanks for closing this pull request! If you have any further questions, please feel free to open a new issue. We are always happy to help! |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @aaronm-2112 - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| } | ||
| } | ||
|
|
||
| if (ineligible) return { shouldShow: false }; |
There was a problem hiding this comment.
suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)
| if (ineligible) return { shouldShow: false }; | |
| if (ineligible) { |
Explanation
It is recommended to always use braces and create explicit statement blocks.Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).
| } | ||
| } | ||
|
|
||
| if (ineligible) return; |
There was a problem hiding this comment.
suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)
| if (ineligible) return; | |
| if (ineligible) { |
Explanation
It is recommended to always use braces and create explicit statement blocks.Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).
| } | ||
| } | ||
|
|
||
| if (ineligible) return; |
There was a problem hiding this comment.
suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)
| if (ineligible) return; | |
| if (ineligible) { |
Explanation
It is recommended to always use braces and create explicit statement blocks.Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).
| } | ||
| } | ||
|
|
||
| if (ineligible) return; |
There was a problem hiding this comment.
suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)
| if (ineligible) return; | |
| if (ineligible) { |
Explanation
It is recommended to always use braces and create explicit statement blocks.Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).
| } | ||
| } | ||
|
|
||
| if (ineligible) return; |
There was a problem hiding this comment.
suggestion (code-quality): Use block braces for ifs, whiles, etc. (use-braces)
| if (ineligible) return; | |
| if (ineligible) { |
Explanation
It is recommended to always use braces and create explicit statement blocks.Using the allowed syntax to just write a single statement can lead to very confusing
situations, especially where subsequently a developer might add another statement
while forgetting to add the braces (meaning that this wouldn't be included in the condition).
|
Summary by Sourcery
Implement guest and editor role checks to conditionally skip pages in the guided mode, add network communication notifications, and update the CI workflow to trigger on a new branch.
New Features:
Enhancements:
CI:
Documentation: