-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME.Rmd
93 lines (62 loc) · 2.7 KB
/
README.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
---
output: github_document
---
<!-- README.md is generated from README.Rmd. Please edit that file -->
```{r, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>"
)
```
# gdrive-automation
<!-- badges: start -->
[![R-CMD-check](https://github.com/c4r-io/gdrive-automation/actions/workflows/R-CMD-check.yaml/badge.svg)](https://github.com/c4r-io/gdrive-automation/actions/workflows/R-CMD-check.yaml)
<!-- badges: end -->
The goal of gdrive-automation is to automate processing and tasks related to the C4R Shared Drive, to aid in synchronization of states and content.
Specific actions include:
- check for updates in Unit Roadmaps and process accordingly (send
notifications, update files)
- check for updates in the Unit Tracking spreadsheet and process
accordingly (send notifications, update files)
- send notifications (via CRM API integraton?)
- log actions
- log todos (actions to be taken by human)
# Data Model
Data about a Unit and its Status is shared across two distinct files:
- the Unit Roadmap (“roadmap”) specific to the unit - a google doc
- the overall Unit Tracking spreadsheet (“tracker”) - a google sheet
The data that is unique in the roadmap is:
- metadata about the unit (title, description, mini-units, activities)
## Resolving Status Updates
Both the roadmap and the tracker will contain status indicators for
various components / phases of a unit. (The technical limitation here is a
pulldown item in a google doc cannot be manipulated through the API. Its value
can be read by exporting the google doc, however.)
There are 4 states for the status, which generally progresses from:
“Not started” -\> “Submitted” -\> “Under review” -\> “Approved”
The below describes the general procedure for resolving situations where the
status for a particular item is different in the roadmap vs. the
tracker.
### Case 0. Identical Status
No action needed.
### Case 1. Tracker is “further along” than the Roadmap
1. Check if a todo already exists for updating the roadmap.
a. if NO, then create a new todo for the update
b. if YES, then no action needed
### Case 2. Roadmap is “further along” than the Tracker
#### Case 2a. “Not started” -\> “Submitted”
1. Update tracker to match.
2. Send notifications as necessary.
3. Log the change.
#### Case 2b. “Submitted” -\> “Under review”
1. Update tracker to match.
2. Send notifications as necessary.
3. Log the change.
#### Case 2c. {anything} -\> “Approved”
(if change is for item that is for METER to review)
1. Update tracker to match.
2. Send notifications as necessary.
3. Log the change.
### Case 3. Anything else.
1. Notify Hao of the discrepancy.
2. Log the discrepancy.