Skip to content

Commit 4873996

Browse files
authored
Merge pull request #7187 from Countly/ar2rsawseen/master2
More docs
2 parents 0769ed0 + dd0ad34 commit 4873996

4 files changed

Lines changed: 215 additions & 2 deletions

File tree

.github/AI_PR_REVIEW_GUIDELINES.md

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
# AI Pull Request Review Guidelines for Countly Server
2+
3+
These guidelines are for AI-based review bots (e.g., GitHub Copilot) to ensure all pull requests (PRs) to Countly Server meet project standards for quality, security, and maintainability.
4+
5+
---
6+
7+
## 1. General Code Quality
8+
- **Linting:** All code must pass ESLint and shellcheck validation. Reject PRs with lint errors.
9+
- **Comments:** Public functions must use JSDoc. Complex logic should be commented, but avoid redundant comments.
10+
- **Error Handling:** All errors must be handled and surfaced to the frontend or logs.
11+
12+
## 2. Backend (Node.js)
13+
- **API Security:** All endpoints must use validation from `api/utils/rights.js` (e.g., `validateRead`, `validateCreate`).
14+
- **Parameter Validation:** All input parameters must be validated and type-checked. Reject PRs with missing or unsafe validation.
15+
- **Cross-App Security:** All write/delete operations must check `app_id` to prevent cross-app access.
16+
- **MongoDB:** Use projections to limit returned fields. Use batchers for frequent/bulk operations. Create indexes for new collections.
17+
- **Audit Logging:** All create/update/delete actions must dispatch `/systemlogs` events.
18+
19+
## 3. Frontend (Vue.js)
20+
- **Component Naming:** Use PascalCase for JS, kebab-case for templates.
21+
- **Props/Events:** Use props down, events up. Do not modify parent state directly.
22+
- **Security:** Never use `v-html` with user input. Use `countlyCommon.encodeHtml()` for manual sanitization.
23+
- **Testing:** All interactive elements must have `data-test-id` attributes for UI testing.
24+
- **Computed Properties:** Prefer computed properties over watchers for derived state.
25+
26+
## 4. CSS & Styling
27+
- **SASS:** Use SCSS syntax and `@use` for imports. Do not use `@import`.
28+
- **BEM:** All new classes must use BEM naming with `cly-vue-` prefix.
29+
- **Bulma:** Use Bulma classes with `bu-` prefix for layout.
30+
- **No Deprecated Paths:** Do not add CSS to deprecated directories.
31+
32+
## 5. Security
33+
- **XSS:** All API output must be escaped. Frontend must treat API data as text. Never use `v-html` with unsanitized input.
34+
- **MongoDB Injection:** Always cast credentials to strings. Validate objects for MongoDB operators.
35+
- **File Uploads:** Only allow whitelisted file types. Sanitize all filenames.
36+
- **Command Line:** Use `spawn` with argument arrays, never `exec` with user input.
37+
38+
## 6. Testing & Documentation
39+
- **Tests:** PRs must include tests for new features, edge cases, and cleanup. Plugins must test app lifecycle hooks.
40+
- **Docs:** Update or add documentation for new/changed features, including JSDoc for public functions.
41+
42+
## 7. Plugin Development
43+
- **Structure:** Plugins must follow the standard structure (`api/api.js`, `frontend/app.js`, etc.).
44+
- **Lifecycle:** Plugins with collections must handle app create/delete and user data deletion events.
45+
46+
## 8. Pull Request Hygiene
47+
- **No Secrets:** PRs must not include credentials, secrets, or sensitive data.
48+
- **Changelogs:** Update `CHANGELOG.md` for user-facing changes.
49+
- **License:** All code must comply with AGPL-3.0 and Countly's Section 7 modifications.
50+
51+
---
52+
53+
**References:**
54+
- [CODING_GUIDELINES.md](../CODING_GUIDELINES.md)
55+
- [SECURITY.md](../docs/SECURITY.md)
56+
- [VUEJS_GUIDELINES.md](../docs/VUEJS_GUIDELINES.md)
57+
- [CSS_STYLE_GUIDE.md](../docs/CSS_STYLE_GUIDE.md)
58+
- [UI_TESTING.md](../docs/UI_TESTING.md)
59+
60+
---
61+
62+
**If a PR does not meet these requirements, request changes with specific feedback.**

bin/README.md

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,2 @@
11

22
Use `bash countly.install.sh` to install Countly.
3-
4-
Run `bash config/countly_user.sh` script which converts Countly process and files under `countly` user.

docs/OBSERVABILITY_GUIDELINES.md

Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
# Countly Server Observability Guidelines
2+
3+
This document describes best practices for logging, debugging, and error reporting in Countly Server. All contributors must follow these guidelines to ensure robust observability and traceability.
4+
5+
---
6+
7+
## 1. Logging Library
8+
- **Always use** `api/utils/log.js` for all logging. Do **not** use `console.log` or similar.
9+
- The logger provides levels: `debug`, `info`, `warn`, `error`.
10+
- Example usage:
11+
```js
12+
const log = require('../../../api/utils/log.js')('crashes:api');
13+
log.d('Debug message');
14+
log.e('Error occurred: %j', error);
15+
```
16+
17+
## 2. Module Naming Convention
18+
- **Plugin files:** Use the plugin name as the logger prefix. Example: `crashes`, `push`, `views`.
19+
- **Submodules:** Separate submodules with `:`. Example: `crashes:api`, `crashes:render`.
20+
- **Core files:** Prefix with `core:`. Example: `core:render`, `core:auth`.
21+
- **Job files:** Prefix with `job:`. Example: `job:crashes`, `job:push`. This allows enabling/disabling logging for all jobs at once.
22+
23+
## 3. Logging Practices
24+
- **Log all errors** and error handling with `error` level (`log.e`).
25+
- **Add debug logs** (`log.d`) at every major step of execution to trace code flow.
26+
- Use `log.i` for important state changes, and `log.w` for warnings.
27+
- Use the logger's `callback` and `logdb` helpers for error logging in async/database operations.
28+
- Example:
29+
```js
30+
log.d('Starting job execution');
31+
// ...
32+
log.e('Failed to process job: %j', err);
33+
```
34+
35+
## 4. Enabling Logging
36+
- **Via Dashboard:** Go to Management → Settings → Logs to configure log levels and modules.
37+
- **Via Environment Variables:**
38+
- Set `DEBUG=*` to enable all debug logs.
39+
- Set `DEBUG=crashes:*,job:*` to enable debug logs for all crashes and job modules.
40+
- Example:
41+
```bash
42+
DEBUG=core:*,crashes:api npm run start:all:dev
43+
```
44+
45+
## 5. Log Level Configuration
46+
- Log levels can be set in `api/config.js` under the `logging` section.
47+
- Example:
48+
```js
49+
logging: {
50+
info: ['core', 'crashes'],
51+
debug: ['job:*'],
52+
default: 'warn'
53+
}
54+
```
55+
- You can also set log levels at runtime:
56+
```js
57+
require('api/utils/log.js').setLevel('job:crashes', 'debug');
58+
```
59+
60+
## 6. Error Handling
61+
- **Always log errors** with `log.e`.
62+
- Use logger's `callback` and `logdb` for async/database error handling.
63+
- Example:
64+
```js
65+
someAsyncOperation(log.callback((result) => {
66+
log.d('Operation completed', result);
67+
}));
68+
```
69+
70+
## 7. Debugging Flow
71+
- Add debug logs at:
72+
- Function entry/exit
73+
- Major state changes
74+
- Before/after external calls (DB, API, etc.)
75+
- All error handling branches
76+
- This enables tracing execution in debug mode.
77+
78+
## 8. References
79+
- See `api/utils/log.js` for advanced usage (sub-loggers, logdb, callback, etc.).
80+
- See [CODING_GUIDELINES.md](../CODING_GUIDELINES.md) for general code standards.
81+
82+
---
83+
84+
85+
## Log Message Formatting
86+
87+
- **Be clear and concise:** Log messages should be easy to understand and provide enough context for debugging.
88+
- **Use structured formatting:** Prefer format specifiers (`%s`, `%j`, `%d`, etc.) for variables and objects. Example:
89+
```js
90+
log.d('Processing user %s with data: %j', userId, userData);
91+
```
92+
- **Include relevant identifiers:** Always log IDs, error objects, and key parameters to help trace issues.
93+
- **Timestamp and level:** The logger automatically adds timestamps and log levels to each message.
94+
- **Consistent style:** Use similar phrasing for similar events across modules (e.g., "Starting job", "Job completed", "Error processing job").
95+
- **Avoid sensitive data:** Never log credentials, secrets, or personal data.
96+
- **Multi-line logs:** For complex objects, use `%j` to pretty-print JSON. For multi-step flows, use separate log statements for each step.
97+
98+
---
99+
100+
**Consistent, structured logging is required for all new code.**

docs/README.md

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
2+
# Countly Server Documentation Index
3+
4+
This README provides a table of contents for all markdown documentation files in the repository, including those in the root, docs, .github, plugins, bin, and other folders.
5+
6+
---
7+
8+
## Top-Level Documentation
9+
- [README.md](../README.md): Project overview, installation, and quick links.
10+
- [CODING_GUIDELINES.md](../CODING_GUIDELINES.md): General coding standards and best practices.
11+
- [CHANGELOG.md](../CHANGELOG.md): Summary of user-facing changes and releases.
12+
- [CONTRIBUTING.md](../CONTRIBUTING.md): How to contribute to Countly Server.
13+
- [SECURITY.md](../SECURITY.md): (Legacy) Security guidelines.
14+
- [CLAUDE.md](../CLAUDE.md): Claude-specific notes.
15+
16+
## docs/ Folder
17+
- [README.md](README.md): This documentation index.
18+
- [SECURITY.md](SECURITY.md): Security requirements and best practices.
19+
- [VUEJS_GUIDELINES.md](VUEJS_GUIDELINES.md): Vue.js frontend development standards.
20+
- [CSS_STYLE_GUIDE.md](CSS_STYLE_GUIDE.md): SASS, BEM, and Bulma CSS conventions.
21+
- [UI_TESTING.md](UI_TESTING.md): Cypress UI testing and data-test-id usage.
22+
- [OBSERVABILITY_GUIDELINES.md](OBSERVABILITY_GUIDELINES.md): Logging, debugging, and error reporting standards.
23+
24+
## .github/ Folder
25+
- [AI_PR_REVIEW_GUIDELINES.md](../.github/AI_PR_REVIEW_GUIDELINES.md): Guidelines for AI-based PR review bots.
26+
- [issue_template.md](../.github/issue_template.md): Issue template for GitHub.
27+
- [copilot-instructions.md](../.github/copilot-instructions.md): Copilot agent instructions.
28+
29+
## test/ Folder
30+
- [README.md](../test/README.md): Test suite documentation and instructions.
31+
32+
## ui-tests/ Folder
33+
- [README.md](../ui-tests/README.md): UI test suite documentation.
34+
35+
## bin/ Folder
36+
- [README.md](../bin/README.md): Installation scripts documentation.
37+
- [scripts/README.md](../bin/scripts/README.md): Bin scripts documentation.
38+
- [scripts/sharding/README.md](../bin/scripts/sharding/README.md): Sharding scripts documentation.
39+
- [upgrade/18.08/mongo.upgrade.instructions.md](../bin/upgrade/18.08/mongo.upgrade.instructions.md): Mongo upgrade instructions.
40+
41+
## api/parts/jobs/ Folder
42+
- [README.md](../api/parts/jobs/README.md): Jobs system documentation.
43+
- [job_flow.md](../api/parts/jobs/job_flow.md): Job flow documentation.
44+
45+
## plugins/guides/ Folder
46+
- [README.md](../plugins/guides/README.md): Plugin guides documentation.
47+
48+
## Other Markdown Files
49+
- Any other .md files found in the repository can be referenced directly by their path.
50+
51+
---
52+
53+
**Tip:** For coding standards, always start with [CODING_GUIDELINES.md](../CODING_GUIDELINES.md). For specialized topics, see the relevant docs above.

0 commit comments

Comments
 (0)