Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

apps/dashboard-api/src/controllers/project.controller.js (3)

310-312: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Remove leftover exploratory comments.

These read like in-progress debugging notes ("Wait, does 'users' collection get automatically added...") rather than documentation, and should be cleaned up before merge.

🧹 Proposed cleanup

       if (template.isAuthEnabled) {
         newProject.isAuthEnabled = true;
-        // The default users collection is appended later or explicitly, let's see. 
-        // Wait, does 'users' collection get automatically added if isAuthEnabled is set?
-        // Let's add it explicitly if not present.
       }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/dashboard-api/src/controllers/project.controller.js` around lines 310 -
312, Remove the leftover exploratory comments near the users collection handling
in the project controller, including the notes about whether the default
collection is appended automatically and adding it explicitly; leave the
surrounding implementation unchanged.

---

315-327: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

Reuse getDefaultRlsForCollection instead of re-deriving ownerField inline.

This block reimplements RLS/ownerField derivation with a simpler rule than the existing getDefaultRlsForCollection (lines 129-148), which already inspects the collection's own schema fields (userId/ownerId) and special-cases users. The inline version here always falls back to ownerField: 'userId' for any non-users collection, ignoring an ownerId field if the template collection has one. For the current sdk-kanban template this happens to match, but a future template collection modeled around ownerId would silently get the wrong ownerField, weakening the RLS enforcement for that collection.

♻️ Proposed refactor

       if (template.collections && template.collections.length > 0) {
         newProject.collections = template.collections.map(col => {
           const mode = typeof col.rls === 'string' ? col.rls : (col.rls?.mode || 'public-read');
+          const defaults = getDefaultRlsForCollection(col.name, col.model);
           return {
             name: col.name,
             model: col.model,
             rls: {
               enabled: mode !== 'public-read',
               mode,
-              ownerField: col.name === 'users' ? '_id' : 'userId',
+              ownerField: defaults.ownerField,
               requireAuthForWrite: true
             }
           };
         });
       }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/dashboard-api/src/controllers/project.controller.js` around lines 315 -
327, Update the template collection mapping to reuse getDefaultRlsForCollection
for RLS configuration instead of deriving ownerField inline. Preserve the
collection-specific mode handling where needed, while allowing the helper to
inspect each collection schema, special-case users, and select userId or ownerId
correctly.

---

387-393: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Use structured error checking for transaction unsupported errors.

Broad substrings like "standalone", "Session", or "replica set" can match unrelated createProject errors while still re-executing key generation, limit checks, and the save as a no-transaction project. Rely on the driver error shape/code for the transaction error, e.g. "Transaction numbers are only allowed..." plus err.codeName === 'IllegalOperation'/err.code === 20, so only unsupported MongoDB transactions trigger the fallback.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/dashboard-api/src/controllers/project.controller.js` around lines 387 -
393, Update the transaction-error detection in the createProject error-handling
path to rely on MongoDB’s structured error indicators rather than broad
“standalone”, “Session”, or “replica set” message matches. Recognize the
unsupported-transaction case only when the transaction-number message is present
together with the appropriate driver codeName or code, such as IllegalOperation
or 20, before re-executing the non-transaction fallback.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

apps/dashboard-api/src/__tests__/project.controller.cloneTemplate.test.js (2)

289-310: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick win

Missing negative-path coverage for transaction rollback.

This test only covers the commit/success path (startTransaction → commitTransaction → endSession). Given the commit summary calls out fixing "transaction error detection in createProject," a companion test that forces a failure mid-transaction and asserts abortTransaction (not commitTransaction) plus endSession are called — and that the error response still follows the standard shape — would directly validate that fix.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/dashboard-api/src/__tests__/project.controller.cloneTemplate.test.js`
around lines 289 - 310, Add a companion failure-path test beside the
transactional success test for createProject that makes a mid-transaction
operation reject, then assert abortTransaction and endSession are called,
commitTransaction is not called, and the response uses the standard error
shape/status. Reuse the existing req, res, and mockSession setup and restore any
mocked failure behavior after the test.

---

249-255: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Error-path tests don't verify the standardized response body.

These tests only check res.status, not that the JSON body follows the { success, data, message } contract expected of all API endpoints, and that no raw/Mongo error details leak through. Given this PR's stated goal of fixing AppError handling and error response formats in createProject, asserting the body shape here would directly validate that fix.

As per coding guidelines: "All API endpoints must return { success: bool, data: {}, message: \"\" }; use AppError for errors, never raw throw, and never expose MongoDB errors to clients."

✅ Suggested additional assertions

   await createProject(req, res);

   expect(res.status).toHaveBeenCalledWith(400);
+  const responseObj = res.json.mock.calls[0][0];
+  expect(responseObj.success).toBe(false);
+  expect(responseObj).toHaveProperty('message');

Also applies to: 257-265

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/dashboard-api/src/__tests__/project.controller.cloneTemplate.test.js`
around lines 249 - 255, Extend the error-path tests for createProject, including
the missing-name case and the additional case around lines 257-265, to assert
the JSON response follows the standardized { success, data, message } contract.
Verify the error response indicates failure, uses an empty data object, provides
the expected safe message, and does not expose raw MongoDB or internal error
details, while retaining the existing 400 status assertions.

Source: Coding guidelines

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes