Product Development

Page tree
Skip to end of metadata
  • Created on 2012-01-11, last edited by Jan Haderka on 2012-07-27
Go to start of metadata
Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 87 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

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 component.

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.
Ex: A company has public website running on Magnolia and an intranet running on Magnolia. Content from the public website could be display on the intranet via a Magnolia Gadget.

12.

 

13.

 

14.

 

15.

 

5 Comments

  1. Boris Kraft

    I think we have to distinguish between two different needs/use cases

    1. ability to use gadgets as components (author instance)
    2. Portal-mode: ability to configure your own environment (public instance).

    1. Samuel Schmitt

      Right. Maybe for a first version we should focus on the use cases from an authoring perspective.

      1. Boris Kraft

        At minimum we need to understand where the differences are in terms of technology to develop.

  2. 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.

  3. 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.