1. 08 Mar, 2015 1 commit
  2. 25 Oct, 2014 1 commit
  3. 16 Oct, 2013 1 commit
  4. 07 Oct, 2013 1 commit
  5. 02 Sep, 2013 1 commit
    • mmn's avatar
      needLogin renamed checkLogin and made a property · f0e967fe
      mmn authored
      Action extended classes now can set 'needLogin' as a protected property,
      which is defaulted to 'false'. However, FormAction defaults this to 'true'
      because most of the form actions will require a current login to be valid.
      
      NewgroupAction, NewmessageAction, NewnoticeAction are all affected by this
      commit and in the future we will migrate each potential formaction to the
      proper class parent tree. :)
      f0e967fe
  6. 01 Sep, 2013 1 commit
    • mmn's avatar
      Proper definition of $args array in NewgroupAction->prepare · 83000f6f
      mmn authored
      Also, there is no need to do 'return' after throwing a ClientError
      Exception. And we'll use the Action->clientError for logging benefits
      until the error handling is properly done all the way to backend.
      83000f6f
  7. 31 Aug, 2013 1 commit
    • mmn's avatar
      NewgroupAction converted to extend FormAction · cfa699e4
      mmn authored
      Had to change Action function 'prepare' to 'protected', as you can't
      (of course) protect something that's been public in a parent class. The
      other way around seems fine for PHP... Eventually all actions will have
      protected 'prepare' (use execute/run)
      
      A feature of the previously fixed initialization of Action classes, is
      that we now have $this->scoped which is the current profile in use. As
      of now that is always a local User, except the corresponding Profile
      object.
      
      Also, instead of calling 'showForm' everywhere, in case of an error we
      just throw an exception of some sort and pass the message along there.
      
      I've also introduced in FormAction the 'showInstructions' function in
      order to get a unified instructions/info/error display method.
      
      TODO: Improve info/error message handling, and what/when/where to show.
      cfa699e4
  8. 18 Aug, 2013 1 commit
    • mmn's avatar
      The overloaded DB_DataObject function staticGet is now called getKV · 2a4dc77a
      mmn authored
      I used this hacky sed-command (run it from your GNU Social root, or change the first grep's path to where it actually lies) to do a rough fix on all ::staticGet calls and rename them to ::getKV
      
         sed -i -s -e '/DataObject::staticGet/I!s/::staticGet/::getKV/Ig' $(grep -R ::staticGet `pwd`/* | grep -v -e '^extlib' | grep -v DataObject:: |grep -v "function staticGet"|cut -d: -f1 |sort |uniq)
      
      If you're applying this, remember to change the Managed_DataObject and Memcached_DataObject function definitions of staticGet to getKV!
      
      This might of course take some getting used to, or modification fo StatusNet plugins, but the result is that all the static calls (to staticGet) are now properly made without breaking PHP Strict Standards. Standards are there to be followed (and they caused some very bad confusion when used with get_called_class)
      
      Reasonably any plugin or code that tests for the definition of 'GNUSOCIAL' or similar will take this change into consideration.
      2a4dc77a
  9. 12 Aug, 2013 1 commit
    • mmn's avatar
      added missing return statement after showForm call · ea837cea
      mmn authored
      Issue #3125 at http://status.net/open-source/issues/3125 (and its duplicate 3127) describe buggy behaviour when trying to create a new group - i.e. the group is still created but with nickname NULL.
      
      The reason the group is created is that when failing Nickname::normalize, the function trySave() in actions/newgroup.php doesn't call 'return' - meaning it just keeps going despite the error thrown. It a
      
      So the simple solution to this bug was adding a return call at line 128, inside the catch just after the showForm(...) call.
      ea837cea
  10. 30 Sep, 2011 1 commit
  11. 04 Apr, 2011 1 commit
  12. 21 Mar, 2011 1 commit
  13. 03 Feb, 2011 1 commit
  14. 28 Jan, 2011 1 commit
  15. 06 Jan, 2011 1 commit
  16. 28 Dec, 2010 1 commit
    • Brion Vibber's avatar
      Prevent group creation by silenced users. · d3d97974
      Brion Vibber authored
      * adds Right::CREATEGROUP
      * logic in Profile::hasRight() checks for silencing
      * NewgroupAction checks for the permission before letting you see or process the form in the UI
      * User_group::register() logic does a low-level check on the specified initial group admin, and rejects creation if that user doesn't have the right; guaranteeing that API methods etc will also have this restriction applied sensibly.
      d3d97974
  17. 29 Nov, 2010 1 commit
  18. 12 Nov, 2010 2 commits
  19. 09 Nov, 2010 1 commit
  20. 02 Nov, 2010 1 commit
  21. 30 Oct, 2010 1 commit
  22. 27 Oct, 2010 1 commit
  23. 21 Oct, 2010 1 commit
  24. 25 Feb, 2010 2 commits
  25. 18 Nov, 2009 1 commit
  26. 13 Oct, 2009 1 commit
  27. 26 Aug, 2009 1 commit
  28. 25 Aug, 2009 4 commits
  29. 21 Aug, 2009 1 commit
  30. 15 Jun, 2009 1 commit
  31. 01 Apr, 2009 2 commits
    • Evan Prodromou's avatar
      Try to do intelligent redirect codes · 5067939e
      Evan Prodromou authored
      After fixing the redirect code output, there are a lot of weirdnesses
      with e.g. form handling. Try to add explicit redirect codes where
      needed -- principly when handling a POST.
      5067939e
    • Evan Prodromou's avatar
      Try to do intelligent redirect codes · c172cbaf
      Evan Prodromou authored
      After fixing the redirect code output, there are a lot of weirdnesses
      with e.g. form handling. Try to add explicit redirect codes where
      needed -- principly when handling a POST.
      c172cbaf
  32. 09 Feb, 2009 1 commit
  33. 07 Feb, 2009 1 commit
  34. 22 Jan, 2009 1 commit