24 Jun, 2015

1 commit

  • - Fixed bug on GET enterprise API showing communities and vice-versa.
    - Improved POST comment API to recieve multiple params, such as Title.
    
    Signed-off-by: André Bernardes <andrebsguedes@gmail.com>
    Signed-off-by: Tallys Martins <tallysmartins@gmail.com>
    Tallys Martins
     

23 Jun, 2015

3 commits


20 Jun, 2015

1 commit

  •   scopes are defined as class methods on the singleton of the class they
      were named instead of the class that calls them, so regardless if they
      are called by Enterprise or Community, they were defined on
      Organization, so #visible_for_person() always gives us
        `WHERE "profiles"."type" IN ('Organization', 'Enterprise', 'Community')`
    
      This wouldn't be a problem if rails 3.2 didn't merge the WHERE clauses
      of nested scopes, which causes the previous filtering by type of
      Enterprise/Community to be thrown away in favor of the broader one.
    
      This was fixed in later rails versions but we want to be able to
      search only for Enterprises or Communities, so I translated the scope
      to a class method on the parent class Organization, so it can be
      inherited by the other.
    Larissa Reis
     

19 Jun, 2015

9 commits


18 Jun, 2015

2 commits


17 Jun, 2015

1 commit


16 Jun, 2015

1 commit


15 Jun, 2015

2 commits


14 Jun, 2015

1 commit

  • Support plugin to be defined as module instead of object
    
    This makes possible for a plugin to be defined as module and have its
    main class defined inside it with the name Base (e.g. MyPlugin::Base).
    
    The advantages of this is to correctly scope plugins constants inside
    the module. There are many conflicts with the core if the plugin is
    defined as klass, for example:
     - if you define a MyPlugin::DisplayHelper you'll get the error 'warning: toplevel constant DisplayHelper referenced by MyPlugin::DisplayHelper' and your class won't be loaded unless you put a "require 'my_plugin/display_helper'"
     - `require` is also needed for contants with the sames of constants declared under Noosfero::Plugin. For example, if you define a MyPlugin::Manager or MyPlugin::Settings, Noosfero::Plugin::Manager or Noosfero::Plugin::Settings will be returned instead of your plugin's definition.
     - other hard to debug errors may also happen.
    
    This also encapsulates loading procedures into methods of
    Noosfero::Plugin.
    
    See merge request !482
    Braulio Bhavamitra
     

13 Jun, 2015

2 commits

  • This makes possible for a plugin to be defined as module and have its
    main class defined inside it with the name Base (e.g. MyPlugin::Base).
    
    The advantages of this is to correctly scope plugins constants inside
    the module. There are many conflicts with the core if the plugin is
    defined as klass, for example:
     - if you define a MyPlugin::DisplayHelper you'll get the error 'warning: toplevel constant DisplayHelper referenced by MyPlugin::DisplayHelper' and your class won't be loaded unless you put a "require 'my_plugin/display_helper'"
     - `require` is also needed for contants with the sames of constants declared under Noosfero::Plugin. For example, if you define a MyPlugin::Manager or MyPlugin::Settings, Noosfero::Plugin::Manager or Noosfero::Plugin::Settings will be returned instead of your plugin's definition.
     - other hard to debug errors may also happen.
    
    This also encapsulates loading procedures into methods of
    Noosfero::Plugin.
    Braulio Bhavamitra
     
  • Braulio Bhavamitra
     

12 Jun, 2015

6 commits


11 Jun, 2015

11 commits