7b5c8d43f1
## Description
This PR has just the struct definition to allow conversation about the design if needed. Future PR(s) will create and populate the struct during restore (in the CLI-layer since this struct is meant to be used to communicate that information) and pass it down the stack to the graph connector
The roadmap has plans for allowing users to
1. change the "root" folder the restore occurs in
1. change the resource owner of the restored items (e.x. restoring items from one user to a different user)
Both options can be enabled at the same time (e.x. restore "Inbox" from user A to "UserAInboxRestore" in user B). When the folder is not given it should default to "Corso_Restore_\<date time\>" and when the resource owner is not given the item should be restored under the original resource owner. As of now, we don't expect to have to have fine-grained control over restoring multiple users to different folders on a per-user basis. However, we may need to restore to specify a folder that is created for multiple users and restored to.
Examples:
**Not expected:** Restore UserA Inbox to folder1 in their hierarchy and UserB to folder2 in their hierarchy
**Expected:** Restore UserA Inbox to Corso_Restore_2022-09-23
POD struct:
```go
dest := selectors.RestoreDestination{
ContainerName: "Corso_Restore_2022-09-23",
}
```
**Expected:** Restore UserA Inbox to UserB Corso_Restore_2022-09-23
POD struct:
```go
dest := selectors.RestoreDestination{
ResourceOwnerOverride: "UserB",
ContainerName: "Corso_Restore_2022-09-23",
}
```
**Maybe expected:** For UserA and UserB, restore Inbox to folder1 in their separate hierarchies
```go
dest := selectors.RestoreDestination{
ContainerName: "Corso_Restore_2022-09-23",
}
```
Given the limited nature of the destination requirement, a POD struct seems like the best option for the foreseeable future. If we need more complex functionality down the line we can expand from this
## Type of change
<!--- Please check the type of change your PR introduces: --->
- [ ] 🌻 Feature
- [ ] 🐛 Bugfix
- [ ] 🗺️ Documentation
- [ ] 🤖 Test
- [ ] 💻 CI/Deployment
- [x] 🐹 Trivial/Minor
## Issue(s)
<!-- Can reference multiple issues. Use one of the following "magic words" - "closes, fixes" to auto-close the Github issue. -->
* #897
## Test Plan
<!-- How will this be tested prior to merging.-->
- [ ] 💪 Manual
- [ ] ⚡ Unit test
- [ ] 💚 E2E
Corso
Corso is the first open-source tool that aims to assist IT admins with the critical task of protecting their Microsoft 365 data. It provides a reliable, secure, and efficient data protection engine. Admins decide where to store the backup data and have the flexibility to perform backups of their desired service through an intuitive interface. As Corso evolves, it can become a great building block for more complex data protection workflows.
Corso supports M365 Exchange, OneDrive, SharePoint, and Teams. Coverage for more services, possibly beyond M365, will expand based on the interest and needs of the community.
Getting Started
TODO - Link to the appropriate page in the published docs.
Building Corso
# Build a binary. Will be placed in bin/
./build/build.sh
# Build a container image
./build/build-container.sh
Containers
Corso images are hosted on ghrc.io.
Rolling release
docker pull ghcr.io/alcionai/corso:{SHA} --platform linux/arm64
Contribution Guidelines
TODO
Code of Conduct
It's important that our community is inclusive and respectful of everyone. We ask that all Corso users and contributors take a few minutes to review our Code of Conduct
License
TODO `