Portal views are badly implemented and designed. It is unlikely anyone is using them. The future of this is frappe/studio.
We are planning to remove this. Would love to know if anyone has a strong reason to keep them.
5 Likes
We have just started implementing them 
1 Like
We have started utilising the portal views for Customers and Suppliers. Apart from few minor problems, these looks fine to us and are really helpful for us.
1 Like
Dear @rmehta, could you tell a bit more about frappe/studio? Are there a description, screenshots (if preliminary), a repo to preview?
Unless there is, you are asking a one-sided question. Which cannot really be evaluated because you lack the comparison, e.g. sufficient knowledge about the alternative. A cat-in-the-bag type of question.
Maybe a part of the portal devs and user will happily switch if presented with a well-integrated, dev-friendly app with a nice UI (or rather: UX, a term much more pragmatic) and a very simple, future-proof migration path for what devs already built and users already use.
It would also be nice to have a clean separation and communication path between backend (internal LAN) and frontend (www-visible portal). This helps keeping internals securely internal and not expose the whole data silo to a node accessible by default to third parties and potential attackers. Some degree of separation wouldn’t be a bad thing, would it?
1 Like
One of the reasons we chose ERPnext over alternatives was the potential self service capabilities for customers through the portal. Turns out the lack of customization made them useless.
In our B2B case everything should be sorted by customer PO number, but that does not even show up on portal pages. Having a portal that we can customize the list view in terms of columns and order while all else is unchanged would help us be way more productive.
i support the idea of removing it and instead looking at a way to digest this type of data from various sources in an automated way.
like @Peer mentioned, it is important that supplier accessible views runs with a limited backend / dataset separate from the main system(s) that usually lives in a VPC/private network.
my wish would be a solution that would be deployable on any host as a static page build. this could be one for all or one for each given supplier depending on the security requirements.
identity and access management would of course be needed. this could either be as a pluggable ‘bring-your-own service’ (i.e. ‘Cloudflare Zero Trust’ / one-time-pin via email) or a standalone frappe-login-service.
form data and file uploads should be simple with minimal dependencies. a job in the main erpnext would securely poll data from each satellite install. validation and queue-for-approval would happen ‘offline’ and notify supplier if data is missing / invalid.
1 Like
Quick update: Portal views will be re-factored into a Vue app on the route /portal with explicit activation of portal views based on configuration. Watch out for the PR when it comes out.
8 Likes