frappe

What is the Frappe framework? When you think about building a web application, you probably think about several technologies working together: a backend framework, a frontend library, a database, authentication, APIs, and a user interface. Traditionally, developers have to select, configure, and integrate these different components before they can even begin building the actual application. _But what if you had a framework that brought most of these essential building blocks together? That's where Frappe Framework comes in._ Frappe is an open-source, full-stack web application framework built primarily with Python 🐍 and JavaScript. It provides developers with the tools needed to build database-driven applications without having to reinvent common functionality every time they start a new project. Whether you're building an enterprise resource planning (ERP) system or a custom business application, Frappe provides a foundation to get you started. Let me know what you think, would you explore the Frappeverse? 😀

Frappe Helpdesk: Customer Service, Made Simple and Effective (3.5k stars) What it does All text below is quoted directly from the project README. >Modern, Streamlined, Free and Open Source Customer Service Software Key Features: - Agent and Customer Portal Views: Dual portals for agents and customers to simplify issue submission and management. - Customizable SLAs: Discover how you can set and track SLAs for better response times. - Assignment Rules: Custom auto-assignment of tickets based on priority, issue type, or workload. - Knowledge Base: Learn how to create and manage help articles to empower users and reduce tickets. - Saved Replies: Pre-written replies for common queries to ensure quick and consistent communication. >wget https://frappe.io/easy-install.py Repository frappe/helpdesk Repository stats |Metric|Value| |:-|:-| |Stars|3,451| |Forks|985| |Last release|v1.31.0 (2026-10-14)| |Languages|Vue 43.6%, Python 32.5%, TypeScript 22.6%| |Contributors|112| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (181 commits), @Copilot (1 commits)| |AI co-authored commits|Claude: 181, Copilot: 1| Main contributor |Field|Value| |:-|:-| |GitHub|@RitvikSardana| |Commits to this repo|2,700 (top contributor)| |Followers|87| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.

Frappe CRM: Simplify Sales, Amplify Relationships (3.9k stars) What it does All text below is quoted directly from the project README. >Frappe CRM is a simple, affordable, open-source CRM tool designed for modern sales teams with unlimited users. Key Features: - User-Friendly and Flexible: A simple, intuitive interface that’s easy to navigate and highly customizable, enabling teams to adapt it to their specific processes effortlessly. - All-in-One Lead/Deal Page: Consolidate all essential actions and details, like activities, comments, notes, tasks, and more, into a single page for a seamless workflow experience. - Kanban View: Manage leads and deals visually with a drag-and-drop Kanban board, offering clarity and efficiency in tracking progress across stages. - Custom Views: Design personalized views to organize and display leads and deals using custom filters, sorting, and columns, ensuring quick access to the most relevant information. - Twilio: Integrate Twilio to make and receive calls from the CRM. You can also record calls. It is a built-in integration. - WhatsApp: Integrate WhatsApp to send and receive messages from the CRM. - ERPNext: Integrate with ERPNext to extend the CRM capabilities to include invoicing, accounting, and more. Repository frappe/crm Repository stats |Metric|Value| |:-|:-| |Stars|3,861| |Forks|1.5k| |Last release|v1.89.1 (2026-10-23)| |Languages|Vue 51.3%, Python 33.5%, JavaScript 11.4%| |Contributors|84| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|None| |AI co-authored commits|Claude: 206, Copilot: 10| Main contributor |Field|Value| |:-|:-| |Name|Shariq Ansari| |GitHub|@shariquerik| |Commits to this repo|4,171 (top contributor)| |Company / Location|Mumbai| |X / Twitter|@shariquerik| |Followers|141| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.

Three authorisation holes in one helpdesk stack: what CVE-2026-111937, CVE-2026-111938 and CVE-2026-111939 have in common Three authorisation holes in one helpdesk stack: what CVE-2026-111937, CVE-2026-111938 and CVE-2026-111939 have in common Helpdesk and CRM software is where customers describe their problems in plain text, which makes it a data store with an unusually low privacy threshold. Three records published on 19 October 2026 against Frappe applications describe authorisation failures that do not need much sophistication to use: a value trusted from the request, an identifier accepted from the caller, and an endpoint that returns more than the caller asked for. Read together, they map a pattern that is worth checking in any in-house application built on a similar framework. The three records - CVE-2026-111939, Frappe Helpdesk before 1.26.0. Authenticated portal users can create tickets impersonating other customers by supplying a raised_by value. An attacker can call the hd_ticket.api.new endpoint with a victim's email to plant phishing tickets in that customer's portal and read the replies through get_ticket_activities. CVSS v3.1 base score in the record is 4.6, vector AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N. - CVE-2026-111938, Frappe CRM before 1.74.0. Authenticated Sales Users can modify other users' call logs by supplying arbitrary call_sid values, attaching attacker-written notes and tasks to victims' call logs, leads and deals through add_note_to_call_log and add_task_to_call_log. CVSS v3.1 base score 4.3, vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N. - CVE-2026-111937, Frappe CRM before 1.81.2. Authenticated Sales Users can access other users' CRM notifications through a missing authorisation check. This entry is part of the same disclosure set and is cited here for completeness; the description is thinner than the other two, so the analysis below leans on the first pair. All three are listed as "Deferred" at NVD. The fixes are release-level: 1.26.0 for Helpdesk and 1.74.0 plus 1.81.2 for CRM, which means two of the records were fixed in different CRM releases rather than one. Failure one: a field that identifies the customer, supplied by the customer Of the three, CVE-2026-111939 is the one with the most interesting consequences. A ticket creation endpoint needs to know who is raising the ticket. If it takes that identity from the request body, the caller chooses the identity. In a portal with customer-visible content, the result is a two-sided problem: the attacker places text in front of the victim, and the victim's replies become readable to the attacker. The second half is the part that turns this from an annoyance into an information exposure. Reading replies from a ticket you did not create is a data leak, and the customer's replies will contain exactly what a support conversation tends to contain: order numbers, addresses, fragments of credentials pasted by mistake, and descriptions of internal systems. The correct implementation does not need a new mechanism. The session already knows who the caller is; the ticket should take raised_by from the session and ignore any value supplied in the payload. Frameworks make this easy to get wrong because their generic record-creation path accepts a document dictionary and their permission layer evaluates the document as submitted. Failure two: an identifier that scopes the wrong thing CVE-2026-111938 is the same mistake with different objects. A call log identified by call_sid is modified by whoever supplies that value. The impact statement is integrity-only, which is consistent with the description: notes and tasks appear on someone else's lead, deal or call record. A 4.3 is easy to wave through, and the score alone does not explain why this matters. In a sales pipeline, a note attached to a deal is a record of what was said to a customer, so an attacker who can add notes can also create a false record of a conversation, and a team acting on that record will do the wrong thing. The bug is not exfiltration; it is integrity in a decision trail. The check that fixes it is a lookup: resolve the call log or deal, confirm the caller is a participant, then write. The framework's permission model can do this if the endpoint is written to use it rather than to act on the identifier in the request. Failure three: a collection that is not scoped to the caller CVE-2026-111937 is the least specified of the three, and it is also the most common shape in custom applications: a list or detail endpoint for "my notifications" that returns the whole table because the filter was applied in the front end. The description says authenticated Sales Users can access other users' CRM notifications, which is enough to state the class and nothing more. Why this pattern clusters in this product family Frappe applications share a metadata-driven model in which doctypes, permissions and endpoints are defined declaratively. That model is genuinely productive, and it also makes object-level authorisation a per-endpoint decision. A REST resource generated from a doctype inherits the doctype's permissions; a custom API method written with @frappe.whitelist() inherits nothing beyond "the caller is logged in". That is the same distinction security teams already make between function-level and object-level authorisation in any API. The framework does not prevent the correct implementation; it just does not force it, and the default for a new method is the cheaper one. Verification for operators - Version inventory. Helpdesk at 1.26.0 or later, CRM at 1.74.0 or later for the call-log fix and at 1.81.2 or later for the notification fix. Two CRM floors are easy to conflate; the higher one covers both. - Endpoint behaviour test. In a staging tenant, authenticate as a low-privilege portal user and attempt both abuse patterns: create a ticket with a different raised_by, and write a note to a call_sid belonging to another user. A fixed build should reject both. - Log review. Look for ticket creation events where the creator recorded in the audit trail differs from the raised_by value. Historical exploitation would show as a mismatch, and on an unpatched build that query is worth running once. - Custom application review. Any in-house Frappe app with whitelisted methods should be checked for methods that accept an object identifier and act on it without an ownership lookup. That is the generic form of CVE-2026-111938. - Notification filters. Confirm that any "my items" list endpoint applies the caller filter server-side. This is testable with two browser sessions. The part that generalises beyond Frappe Three records, three different objects, one lesson: an identifier in a request is a claim, not a fact. The claim has to be checked against the session, and the check has to happen on the object the write or read actually targets. Framework documentation rarely states this because it is assumed knowledge; incident write-ups state it because it was not. For anyone building on a metadata-driven framework, the practical rule is to treat every custom endpoint as an API in a foreign system: authenticate the caller, authorise the object, then act. The framework will not do the second step for a hand-written method, and the advisories above are what that omission looks like when it ships. Limits The NVD entries are deferred and the scores above are as recorded, not a measured business impact. This article does not claim exploitation in the wild, does not describe a proof of concept beyond the vendor description, and does not assert that every custom endpoint in these applications is affected. CVE-2026-111937's description is thinner than its siblings, and the analysis marks where it rests on inference rather than a stated mechanism. References - NVD record for CVE-2026-111939: nvd.nist.gov - NVD record for CVE-2026-111938: nvd.nist.gov - NVD record for CVE-2026-111937: nvd.nist.gov - Frappe Helpdesk advisory GHSA-xf93-jjcj-44vm: github.com/frappe/helpdesk/security/advisories/GH… - Frappe CRM advisory GHSA-843p-qp2f-p2v8: github.com/frappe/crm/security/advisories/GHSA-84… - Frappe Helpdesk release v1.26.0: github.com/frappe/helpdesk/releases/tag/v1.26.0 - Frappe CRM release v1.74.0: github.com/frappe/crm/releases/tag/v1.74.0

@HarriesSteele 我之前试过改造这个，加入一些 mcp 和 cli 功能给agent 用 frappe/erpnext

Two big merges in Frappe Framework this week. Studio - Powerful visual app builder Flow - AI assistant Coming soon in Version 16. frappe#44825 frappe#44946

guys we ball. RCE in frappe. github.com/frappe/frappe/security/advisories/GHSA… t.co

@LuchoCAB68 Hay uno que capaz te sirva para lo que decís, revisalo. Si no te das maña para instalarlo tiraselo al amigo Claudio. Hay varias versiones d está app que meten features para arg pero no lo he visto. frappe/erpnext

ERPNext just crossed 40k stars on GitHub. On to 50k! ⭐️ frappe/erpnext t.co

Frappe / ERPNext v16.50: The Future of Desktop Icons and Desk Navigation What “retiring” really means, what changed in v16.50, and how custom apps should prepare By Mohamed Hamed (@m7amedenho) Published: October 2026 Frappe Framework and ERPNext v16.50 introduce a clearer navigation model for the Desk. The official hierarchy is now: App └── Module └── Sidebar ├── DocTypes ├── Reports ├── Pages ├── Workspaces └── Dashboards This change raises an important question for developers and implementers who already use the Desktop Icon grid: > Is Desktop Icon being removed, and should custom apps stop using it immediately? The short answer is: The old Desktop Icon grid still works as a compatibility fallback for upgraded sites, but it is retiring. New development should target the Apps screen, Dock, module sidebars, and the new navigation hierarchy. That distinction matters. “Retiring” does not mean “deleted in v16.50,” and it does not mean that every Desktop Icon-related mechanism suddenly stopped working. --- 1. What v16.50 actually changed Frappe describes v16.50 as a polished v16 rather than v17. The release focuses heavily on navigation and user experience while attempting to minimize breaking changes. The redesigned Desk has a much clearer information hierarchy: Apps screen ↓ Application ↓ Dock of modules ↓ One sidebar per module ↓ DocTypes, reports, pages, workspaces, and dashboards The Desktop page now focuses on applications. After a user opens an app, its modules appear in the Dock. Opening a module provides the sidebar associated with that module. This is more than a visual redesign. It changes how navigation should be modeled in a large Frappe application. The official v16.50 announcement describes the hierarchy as: > App → Module → DocTypes, Reports, Pages, Workspaces, Dashboards, and everything else. See the official v16.50 announcement. --- 2. What happens to an existing Desktop Icon grid? An upgrade does not immediately delete an existing site's Desktop Icons or their arrangement. According to Frappe's migration documentation: - A site already using the Desktop Icon grid keeps using it after the upgrade. - Its icons and their arrangement are retained. - The grid remains available as a fallback while the site moves to the Apps screen. - New sites start on the Apps screen rather than the old grid. - The grid will be removed in a future release after most sites have migrated. In other words: Existing upgraded site ↓ Desktop Icon grid remains available ↓ Temporary compatibility fallback ↓ Migration to Apps screen ↓ Future removal of the old grid The documentation does not currently promise a specific removal version. It would therefore be inaccurate to claim that the grid will definitely disappear in v17, or in any other named release, until Frappe announces that explicitly. See Migrating a Version 16 site to the new Desk navigation. --- 3. Desktop Icon, Desktop grid, and Apps screen are not the same thing Some of the confusion comes from using “Desktop Icon” to describe several related concepts. The Desktop Icon grid This is the old home-screen experience containing a grid of icons. It is the part that the official documentation describes as a retiring fallback. Desktop Icon records These are records used by the legacy grid and by migration or compatibility behavior. Their continued presence is not, by itself, evidence that the old grid remains the recommended architecture. The Apps screen This is the forward-looking Desktop experience. It shows one entry per application and leads the user into that app's modules, Dock, and sidebars. Therefore, seeing a Desktop Icon DocType or related code in the framework should not be interpreted as a recommendation to base new application navigation on the old grid. It exists because Frappe must support real installations while they migrate. --- 4. Why would Frappe maintain something that is retiring? Deprecation and maintenance can happen at the same time. ERP installations cannot safely switch navigation models overnight. Existing sites may contain: - custom Desktop Icons; - user-specific icon arrangements; - public and private Workspaces; - custom Workspace Sidebars; - role-dependent shortcuts; - bookmarks and direct links; - multiple custom apps with their own navigation conventions. Frappe therefore needs to preserve the old experience long enough for administrators and developers to migrate safely. Fixing bugs in that compatibility layer does not contradict its future removal. It means the project is supporting the transition instead of breaking upgraded sites immediately. --- 5. Reading the GitHub issues correctly The GitHub issue history contains reports involving Desktop Icons, Workspaces, layout persistence, permissions, caching, and Workspace Sidebars. These reports need chronological context. They should not all be presented as evidence that Desktop Icons are currently broken. Some issues were reported during active v16 development and later fixed or released. For example, the Desktop Icon caching issue #36325 was closed and its fix was released in v16.7.0. At the same time, it would also be inaccurate to claim that every Desktop Icon issue has been resolved. At the time of writing, reports such as creating an icon from the Desktop Icon list #36953 and the broader layout and shortcut report #38292 remain open. The responsible interpretation is: > The issue history documents an active transition and stabilization process. It contains both completed fixes and unresolved edge cases. When evaluating an issue, check: 1. When it was opened. 2. Which branch and version it affects. 3. Whether it is open or closed. 4. Whether a pull request was merged. 5. Whether the fix has a released version. 6. Whether the behavior still reproduces on the version you deploy. This is more useful than treating every historical issue as a current production defect. --- 6. What should custom app developers use now? For a new custom app, start with the Apps screen and the new navigation structure. Declare the application in hooks.py using add_to_apps_screen: add_to_apps_screen = [ { "name": "my_app", "logo": "/assets/my_app/images/logo.svg", "title": "My App", "route": "/desk/my-module", "has_permission": "my_app.utils.check_app_permission", "sequence_id": 50, } ] The fields have distinct responsibilities: | Field | Purpose | | --- | --- | | name | The internal app name | | logo | The icon used on the Apps screen and app Dock | | title | The label shown to the user | | route | The destination opened from the app icon | | has_permission | Optional function controlling access to the app | | sequence_id | Optional ordering value; lower values appear first | After registering the app, organize its navigation around: Custom App ├── Module A │ ├── Module Sidebar │ ├── Workspaces │ ├── DocTypes │ └── Reports └── Module B ├── Module Sidebar ├── Pages └── Dashboards The official developer example is available in The desktop and Apps screen. Do not treat add_to_apps_screen as the entire navigation architecture. It places the application on the Apps screen; the Dock and module sidebars provide the structure inside the application. --- 7. A practical migration plan for an existing site The safest strategy is not to delete old icons manually. It is to audit, migrate, test, and then switch. Step 1: Take a complete backup Back up the database, public files, private files, site configuration, and the exact revisions of all installed apps. A database backup alone is not a complete rollback plan. Step 2: Rehearse on staging Restore production data into an isolated staging environment and run the upgrade there first. Navigation is permission-sensitive, so a successful Administrator test is not enough. Step 3: Inventory current navigation Record: - Desktop Icons and their routes; - customized icon arrangements; - public and private Workspaces; - customized Workspace Sidebars; - role-specific links; - custom Pages and Reports; - custom apps that still ship an older sidebar format. Screenshots are useful here because they make post-migration comparison much faster. Step 4: Review migration output Note any modules that were merged, Workspaces placed under Custom Workspaces, and apps still using an older sidebar format. Step 5: Assign every Workspace to the correct module In the new structure, a Workspace belongs to a module because that module determines where the Workspace appears. Treat Custom Workspaces as a migration to-do list rather than a permanent information architecture. Step 6: Curate module sidebars Review the generated sidebars and rebuild anything that was not carried over. Prefer one clear, curated sidebar per module. Step 7: Test with real user roles Test as ordinary users from different departments. Verify: - application visibility; - module visibility; - sidebar contents; - Workspace access; - DocType and Report permissions; - old bookmarks and direct links; - the app icon's landing route; - mobile and smaller-screen behavior. Step 8: Switch the Desktop page When staging validation is complete, open Desktop Settings, set Desktop Page to Apps, and save. This setting affects all users. While the fallback remains available, the site can temporarily return to Desktop Icons without deleting the stored icons or arrangements. Step 9: Monitor and document After production rollout, collect feedback from real users, fix missing navigation entries, and document the final module ownership and sidebar structure. --- 8. Important migration risks The official migration guide identifies several details worth checking carefully: - Site-level sidebar changes may not be carried over when an app ships a new sidebar for the same module. - Some legacy icons may be hidden if they opened a sidebar that no longer maps cleanly to a Workspace or module sidebar. - Old sidebar records may remain as a read-only archive for recovery purposes. - Existing /desk/... and /app/... links are intended to continue working and may be normalized to the new route structure. - A Workspace without a correct module assignment can be difficult for users to find. These are strong reasons to test with a copy of production data before switching the whole site. --- 9. Why this architecture makes sense A free-form icon grid becomes harder to manage as an ERP grows. Consider a system with: - many installed applications; - dozens of modules; - hundreds of DocTypes; - many Reports and Workspaces; - different access rules by role; - user-specific navigation preferences. A hierarchy such as: App → Module → Sidebar → Resource creates clearer ownership. It answers practical questions: - Which app owns this functionality? - Which business module does it belong to? - Which sidebar should expose it? - Which users are allowed to see it? - Where should a user land after opening the app? This structure also makes custom apps easier to reason about and maintain than a growing collection of independent icons. --- 10. The conclusion for v16.50 The correct interpretation of Frappe / ERPNext v16.50 is not: Desktop Icons were deleted. It is: The old Desktop Icon grid remains temporarily for compatibility. The new Apps → Modules → Sidebar hierarchy is the target architecture. Existing sites should migrate deliberately. New custom apps should build for the new model. For existing ERPNext installations, there is no reason to panic or delete the legacy configuration immediately. Preserve it, test the conversion, and move users only after the new navigation has been validated. For developers starting new projects, the direction is already clear: register the application on the Apps screen, define its modules and Dock, and curate one useful sidebar per module. The practical workflow is: Back up → Audit → Upgrade on staging → Organize → Test → Switch → Monitor That approach respects existing users without building new technical debt around a grid that Frappe has officially said will be removed in a future release. --- References Official sources - Announcing Framework, ERPNext and Frappe HR v16.50 - Official v16.50 announcement on the Frappe Forum - Migrating a Version 16 site to the new Desk navigation - The desktop and Apps screen in Frappe Framework - Migrating to version 16 — Frappe Wiki Selected GitHub issues - #36325 — Caching issue for Desktop Icons — fixed and released in v16.7.0 - #36953 — Cannot create a functional Desktop Icon from the list — open at the time of writing - #38292 — Desktop Icon layout, shortcut, and folder issues — open at the time of writing > Issue states can change after publication. Check each issue directly before using its current status in a migration decision. --- Author's note I'm Mohamed Hamed (@m7amedenho), a software developer working with ERPNext and Frappe Framework. I wrote this article to organize what I learned while investigating the navigation changes in v16.50 and to help other developers approaching the same migration. If you have migrated a customized v16 site to the new navigation, I would be interested to hear which Desktop Icon, Workspace, or Sidebar behaviors required the most attention in your environment.