

Your Rating: |
![]() ![]() ![]() ![]() ![]() |
Results: |
![]() ![]() ![]() ![]() ![]() |
89 | rates |
GREYProvide more flexible module then formerly developed magnolia-opensocial, but based on same APIsGREY
Rationale
In 2011, we developed a module providing an openSocial container - Magnolia Opensocial Module.
The development of this module was driven by customer requirements, the status is beta and it's developed for Magnolia 4.4 and based on Opensocial 1.1.
(Here info about this module).
For all these reasons, I suggest that we start the development of a brand new module providing portal-like features
- running on Magnolia 4.5
- based on the Opensocial 2.0
So we won't discuss later these technical requirements.
The goal of this page is to describe and to discuss the requirements, and then, from this, define a list of features to implement for the first version.
Goal of the module
Without going too much in detail, there is the requirement section for that, I summarize briefly the goal of this module.
It provides portal features, meaning:
- Aggregation of information coming from internal and external services/sources
- Personalization / customization of end-user view
- Security on gadget level
Requirements
As inputs, we could take care of
- what was done in the Magnolia Opensocial Module
- the tech brief about Portal
But of course, fresh ideas are welcome.
For a common language, the first thing to define is the name of the module.
Module Name: TBD
The table below collect all the requirements.
|
Requirements |
---|---|
1. |
Author can put on any pages, in any areas a gadget container. Indeed, the container will be provided by a |
2. |
Author can add gadgets in the gadget container. |
3. |
Author can apply security on gadget level. It means that from a same page, a basic user could see 2 gadgets while a super user could see 4 gadgets |
4. |
Gadget could be registered within Magnolia |
5. |
Public user can add gadget on a page (containing a gadget container!). |
6. |
Public user can move gadget within a gadget container. |
7. |
A list of registered gadget is available for the public user. This list displays only the gadgets the user can access. |
8. |
Communication between gadgets of a same container is enabled |
9. |
The author can define if a container is editable by a public user. When it's not editable the user cannot add a gadget and cannot move gadgets. |
10. |
Gadget container host external services (like Google gadget) or internal |
11. |
Magnolia gadgets are available. A Magnolia gadget is a content provider, it could be a way to share content across several instance running on Magnolia or on any system providing a opensocial container. |
12. |
|
13. |
|
14. |
|
15. |
|
5 Comments
Boris Kraft
I think we have to distinguish between two different needs/use cases
Samuel Schmitt
Right. Maybe for a first version we should focus on the use cases from an authoring perspective.
Boris Kraft
At minimum we need to understand where the differences are in terms of technology to develop.
Boris Kraft
For now I would keep the original name OpenSocial Module (e.g. v2). Depending on the scope we could call it Portal Module.
Daniel Lipp
Security requirements should be defined very early. There's the need for permissions (what user may use what gadgets) but also for more complex things like how a gadget (might be hosted externally) can grant access to it's data. OAuth it the thing to check there.
Another important security related topic is SSO.