Details

    • Type: Candidate Proposal Candidate Proposal
    • Status: Unsponsored Contribution
    • Resolution: Unresolved
    • Fix Version/s: None
    • Labels:
      None
    • Project Preface:
      Portlet will use uPortal's mailing list with the preface "cmp"
    • Initial Committers:
      Hide
      Cris J. Holdorph
      holdorph@unicon.net

      Misagh Moayyed
      misagh_moayyed@hotmail.com

      Yalcin Kaya
      yalcin_kaya@hotmail.com

      Nick Sheets
      nsheets1@gmail.com

      Raymond L Terry
      rterry1@asu.edu
      Show
      Cris J. Holdorph holdorph@unicon.net Misagh Moayyed misagh_moayyed@hotmail.com Yalcin Kaya yalcin_kaya@hotmail.com Nick Sheets nsheets1@gmail.com Raymond L Terry rterry1@asu.edu
    • Technology Overview:
      Content Management portlet supports JSR168. It also uses JSR170 as its content repository API with Apache JackRabbit as the implementation provider. Apache Velocity, ClamAV Antivirus and FCK Editor have also been incorporated into the project.
    • Community Description:
      Project does not have user base yet. However, it was originally developed at Arizona State University, Polytechnic campus and demoed to an audience as part the campus Trade Show Day.
    • JASIG Relationships:
      Portlet complements uPortal and other sites using any JSR168 portlet. It also may use uPortal's roles and directory services in the future to configure user roles, particularly authors.
    • Benefits to Higher Education:
      Hide
      Portlet allows the campus community to seamlessly contribute and publish web content. Simple and easy to use, portlet allows non-technical users and faculty to quickly get in touch with their audience and independently administer and publish centralized content thus lowering web support costs and requirements.
      Show
      Portlet allows the campus community to seamlessly contribute and publish web content. Simple and easy to use, portlet allows non-technical users and faculty to quickly get in touch with their audience and independently administer and publish centralized content thus lowering web support costs and requirements.
    • References:
      N/A
    • Licensing Checklist:
      license file in designated location, all non-licensed or license-incompatible dependencies removed from code base, corporate contributor license agreement on file, individual contributor license agreement on file, license header added to all source files
    • Copyright Checklist:
      notices file in designated location, all source copyright statements added to notices file
    • Trademark Checklist:
      project name does not violate trademark
    • Community Checklist:
      new committers are admitted according to Jasig practices
    • Community Notes:
      not yet released. No known users of this in the community.
    • Governance Checklist:
      steering committee has been created or assigned, jasig voting practices have been adopted, project has weathered and resolved conflicts as needed, release plans are developed and executed in public, engagement with the larger jasig community
    • Alignment Checklist:
      integration with other jasig projects where appropriate, synergy with other jasig projects where possible
    • Infrastructure Checklist:
      subversion module has been created on jasig server, mailing lists have been used, project roadmap is in confluence, project website is kept current, all non-sensitive (i.e. passwords, etc) information in the above tools is publicly accessible

      Description

      Content Management Portlet is developed for uPortal to allow authorized users to administer content remotely. Using this portlet, content authors can remotely edit and publish content independently, and pull in and share existing data and re-purpose it according to different needs. Project supports multiple languages and further allows decoration of content with graphics, links, and templates.

        Activity

        Hide
        Misagh Moayyed added a comment -

        If you have registered multiple instances of the portlet on the page, by default they all would display the same content because the default configuration of all portlets points to the same spots in the underlying content repository.

        If you wish for a portlet to administer its own content, in the preferences screen when you deploy, specify the new location of the repository to which the portlet should write content.

        Show
        Misagh Moayyed added a comment - If you have registered multiple instances of the portlet on the page, by default they all would display the same content because the default configuration of all portlets points to the same spots in the underlying content repository. If you wish for a portlet to administer its own content, in the preferences screen when you deploy, specify the new location of the repository to which the portlet should write content.
        Hide
        Paul Kim added a comment -

        Thank you for kind answer, but one more question here though.
        Noticed "Role configuration (author/viewer) is done within the portal itself via PAGS."
        But I am still stuck in to figure out the way how to add some specific users for specific registered portlets. Does that comment mean some groups under PAGS are supposed to be authors of Portlet? Could you please add more details of this?

        Show
        Paul Kim added a comment - Thank you for kind answer, but one more question here though. Noticed "Role configuration (author/viewer) is done within the portal itself via PAGS." But I am still stuck in to figure out the way how to add some specific users for specific registered portlets. Does that comment mean some groups under PAGS are supposed to be authors of Portlet? Could you please add more details of this?
        Hide
        Misagh Moayyed added a comment -

        Yes. You can allow certain groups native to the portal environment to be classified as "authors". This is pretty much portal agnostic and it is up to you to decide what groups are considered as such. By default, "local.2" of the PAGS group is considered to be of role "author".

        I update the wiki with some additional notes on how this is internally done:
        https://wiki.jasig.org/display/PLT/Content+Management+Portlet

        Show
        Misagh Moayyed added a comment - Yes. You can allow certain groups native to the portal environment to be classified as "authors". This is pretty much portal agnostic and it is up to you to decide what groups are considered as such. By default, "local.2" of the PAGS group is considered to be of role "author". I update the wiki with some additional notes on how this is internally done: https://wiki.jasig.org/display/PLT/Content+Management+Portlet
        Hide
        Paul Kim added a comment - - edited

        One more question for repository configurations here. Would you let us know how we can keep the contents for each channel when we move the tomcat for such upgrade? Is it supposed to keep the contents with data-export and data-import and copying the repository folder at "/webapps/ContentManagementPortlet/WEB-INF/config/repository/repository"? Thank you.

        Show
        Paul Kim added a comment - - edited One more question for repository configurations here. Would you let us know how we can keep the contents for each channel when we move the tomcat for such upgrade? Is it supposed to keep the contents with data-export and data-import and copying the repository folder at "/webapps/ContentManagementPortlet/WEB-INF/config/repository/repository"? Thank you.
        Hide
        Misagh Moayyed added a comment -

        All repository data, that is the published content, should be stored in the location referenced by "jcr.repository.path". By default this location is set to $

        {tomcat.dir}

        /webapps/ContentManagementPortlet/WEB-INF/config/repository. This is useful for development and testing where everytime you redeploy the portlet app, the repository will be wiped clean and you'll be given a fresh state since the repo exists inside the deployed webapp.

        In practice, you should externalize this location outside the tomcat environment in a spot that is safe and secure and consistently backed up and has sufficient space available for more content. Then, your maintenance effort would largely remain separate and independent of the repo.

        data-import and data-export only affect portlet preferences, the settings you note when you are in the config mode at the time you deploy the portlet. The actual content is kept inside the repo and is separate from uPortal's functionality.

        Show
        Misagh Moayyed added a comment - All repository data, that is the published content, should be stored in the location referenced by "jcr.repository.path". By default this location is set to $ {tomcat.dir} /webapps/ContentManagementPortlet/WEB-INF/config/repository. This is useful for development and testing where everytime you redeploy the portlet app, the repository will be wiped clean and you'll be given a fresh state since the repo exists inside the deployed webapp. In practice, you should externalize this location outside the tomcat environment in a spot that is safe and secure and consistently backed up and has sufficient space available for more content. Then, your maintenance effort would largely remain separate and independent of the repo. data-import and data-export only affect portlet preferences, the settings you note when you are in the config mode at the time you deploy the portlet. The actual content is kept inside the repo and is separate from uPortal's functionality.

          People

          • Assignee:
            Unassigned
            Reporter:
            Misagh Moayyed
            Project Lead:
            Misagh Moayyed
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: