In order to proceed with the Dashboard implementation it will greatly help sharing the requirements for this new feature.
A specific backoffice OFBiz screen that is reached by pressing on the "Dashboard" button. There is only one Dashboard screen in all the OFBiz system.
Every single page that can be displayed in the Dashboard screen. The portal page is a screen that is defined at run-time by the user selecting several portlets and placing them in columns.
A single piece of UI that is available for the user and that can be located in one or more Pages. Applications "register" their own screens as portlets and they become available in the Dashboard system.
1.1 The Dashboard should be the OFBiz backoffice "home" page
1.2 Multiple Pages should be allowed and the user should be able to select the desired page using a drop-down (DONE)
1.3 User should be able to create as many new "private" pages as needed (if they have the related b. permission) (DONE) (TO DO: permission b. check)
1.4 The pages that the user can select are all his own pages (the ones he has created) plus the "system" pages
1.5 The "system" pages can be created only by users with a specific permission (a. permission)
2. Portal Pages
2.1 User should be able to delete his "private" pages (if he has the b. permission) (DONE) (TO DO: permission b. check)
2.2 User should be able to edit his pages. This means: (if he has the b. permission) (DONE) (TO DO: permission b. check)
2.2.1 Add/Remove columns (DONE)
2.2.2 Set column sizes
2.2.3 Add/remove portlets (DONE)
2.2.4 Configure portlets (attributes change) (DONE)
2.2.5 Move a portlet to another page (DONE)
2.2.6 Move a portlet to a different column or row on the same page (DONE)
2.3 User should be able to create a new page starting from another already existing page (page copying). This will let users to copy a "system" page into a private page and to change it.
2.4 When adding a new portlet to a page the user should be offered all the portlets available in the system (DONE)
3.1 Every application should define the portlets that are needed to the user adding related entity in the database (DONE)
3.2 A path to a screen that renders the portlet should be specified in the Portlet entity (DONE)
3.2 An optional path to a screenshot image of the portlet could be added in the Portlet entity. The image will be visible to the user when he is asked to select a portlet to add to a page (DONE)
3.3 An optional configuration form for the portlet could be added in the Portlet entity. This should be a simple form extending from a predefined form and will be used to edit some portlet specific attributes.
For example a portlet that shows a list of items could have an attribute defining the max number of elements to show. Every single portlet occurrence will have its own attributes. (DONE)
3.4 The portlet should not check if the user has enough permission to view the portlet. This will be checked in the Application inside the screen (and optionally the editing form) definition. (DONE)
- Dashboard system specific Permissions needed -
a. Create/Edit/Delete "system" pages
b. Create/Edit/Delete "private" pages
Hi Bruno, i am trying to use the system to convert the mypage component to the myportal component using the portal system and found the following:
1. I would like to setup a standard number of portalPages with a standard number of portlets. If a new user goes to the myportal component i would like to check if this user has already his private set, when not it will be copied from the standard set and from that point on, he can modify it as he likes.
Could we move the ownerUserLoginId field into the key of the PortalPage Entity to make this possble? ie have a system set and a userset?
2. if number one is implemented i would be nice to have a button to go back to the 'out of the box config'.
Would it also be possible to separate the setup and the usage of the pages? I would like the myportal component look the same as the mypage screens, so without the config info. For that i would like to use the 'preferences' button. So is it possible the split up the display- and the topmenu part of portalpage.ftl?
Could you consider these changes?
thanks in advance,
thank you for your comments.
About your #1. In the requirement 1.4 I thought that "the user can select are all his own pages (the ones he has created) plus the "system" pages".
So what you call the "standard" pages could be these "system" pages that are created by the administrator. This feature is not yet implemented (but at least specified in 1.4 and so it is in my job list but I am more that happy if you beat me). I was thinking to add a "pagetype" field the portalPage entity for this to distingish between standard and system pages.
In requirement 2.3 it is specified that "User should be able to create a new page starting from another already existing page (page copying). This will let users to copy a "system" page into a private page and to change it."
This is how I thought a user could personalize a "system" page, yust copying it into a private page.
About your #2. The original and the new page are always available to the user and to it can always revert to the original one by deleting its private and starting over again.
Of course even requirement 2.3 is not yet implemented (as indicated by the missing DONE flag)
I have a last think I do not clearly understand on the myportal component.
If we implement requirement 1.1 we will have a "central" "Dashboard" page that is reachable from every application menu and hopefully even from the OFBiz logo.
Do you agree that in this case there is no need to have a MyPortal tab to select? I mean the MyPortal component should only implement portlets and make it available to the "system" dashboard. Don't you think so?
For the splitting of the topbar I do not know if you are using my additional path that I have submitted in the jira OFBIZ-2057.
If you apply that patch that is not yet committed, you will see the dashboard system working with also the page selection. I want to say, with this, that the dashboard header will also usefull to select between available pages.
1. Concerning the dashboard i need a central login url for the central dashboardpage what mypage is now, other components cannot be used because they require a basic permmission. Then dependent on the security setting of that userlogin a certain standard screenset is required which optionally, under a preference button, can be modified by the user. The screens however should show the same as now so they can be be mixed with the existing screens and everything still looks the same.
2. The dashboard should follow the standard user interface and different pages should be accessed by application buttons as you can see in the myPortal patch i provided to you. That is also why i want a preference button to follow the current userinterface standards.
2. Then inside the system it would be nice to use the portal system for pages which show a number of portlets like the overview screens for invoice, partyprofile, custrequest etc to be implemented as a dashboard page which the user can optinally modify. Screens that allow modification will show a preference button.
3. perhaps in the future all screens should be portal screens which can be modified by adding or removing portlets.
Currently I am blocked by the inability to have system and usersets of pages. As i said if you would put the ownerUserlogin into the primary key of the portal page entity would enable me to setup system pages for the userlogin _NA_ and can then be easily copied to the records of the specific userlogin.