| Age | Commit message (Collapse) | Author |
|---|
|
part ofthe gallery module. Create the jQuery widget, form template and library to support generalized in place editting. Part of the fix for ticket #750.
|
|
configuration. This allows the ldap installer to instantiate the ldap Identity provider to use in the install and uninstall methods
|
|
the identity provider isn't writable, the method implementations should throw an Invalid Operation exception.
|
|
provider everybody method
|
|
IdentityProvider interface.
|
|
|
|
menu.html.php. This serves two purposes:
1) It's more efficient since we're doing less passes over the Menu tree
2) We're allowing themers to decide whether or not to show empty menus
|
|
can override them and define their own menu formats. I worry a little
bit that this approach may be too heavy since we're now doing a lot
more template includes than we were before. Also, I had to change the
Menu API to stop using __toString() because you can't throw exceptions
from __toString() which would make it an unhappy experience for
developers.
|
|
|
|
|
|
changing providers.
|
|
Create a helper class called identity to simplify call the Identity Provider. Move the contents of MY_Session.php to the new helper class and remove the MY_Session class
|
|
users are logged onto the system. Addressed the issue by adding try/catch logic to the Session::load_user() method. If load_user fails for any reason, then assume that the identity provider has changed, destroy the current session and redirect to the root album.
|
|
|
|
|
|
to use it to get the group it is modifying
|
|
access_Core::_get_all_groups() to use this to get the defined groups.
|
|
What I've tested to this point, is you can install a new provider, switch to it, login as administrator, uninstall the default user module, reinstall the user module, switch back to the user module and login.
|
|
the user module
Bagging the User_Definition and Group_Definition abstract classes and replacing them with interfaces with the same names.
Make sure all the unit tests work.
|
|
installed
|
|
Identity constructor to look in module::get_var(gallery, identity_provider) for the current identity driver.
In addition, don't just arbitrarily lock the use module. Only lock gallery and the module that is referenced by "user_driver_module" variable.
|
|
MY_Session class to provide the user state changes in the session and a login.php helper that has the login form.
|
|
redundant code in the user module and remove references to the Identity helper from the user module as the user module should be able to access things directly. Simplify the get_user_list api method to just accept an array of ids to return user objects for.
|
|
and group.php. Tried creating a identity helper, but the helper identity.php was confused with the library Identity.php. So got around this by making the methods on Identity static and calling the instance within the static methods. Also temporarily moved the user.php and group.php back into the user module.
|
|
module. The premise is that the plugable user module will provide the update screens if the user backend supports updates.
|
|
be active at a given time.
|
|
Conflicts:
modules/gallery/controllers/admin_users.php
modules/gallery/controllers/password.php
modules/gallery/helpers/group.php
modules/gallery/helpers/user.php
modules/notification/helpers/notification.php
|
|
and display if the Identity driver does not support writes. This is set in the config.identity.php
|
|
opposed to return it.
|
|
drivers early in the process so the session deserialization works.
|
|
|
|
classes which extend the User_Definition and Group_Definition classes defined in the Identity API
|
|
Identity/Gallery::list_groups
|
|
|
|
Create an Identity library that defines the interface the Gallery3 expects
Move the user and group helpers into the gallery module to provide the familiar
interface into the Identity library.
Create a Gallery Identity back-end that is supplied by the user module.
The vision here is that all user and group code that is gallery or ui specific
is contained within the core product. Anything that relates to manipulating a
user or group is contained in the back end code that can be replaced.
|
|
shared images from wind to lib. Deleted unused images in the admin_wind. This will likely break a few ajax features.
|
|
to the document root. Instead ignore all th path parts until one of application, modules, themes, or libs is found. Fixes ticket #827
|
|
and classes in the login/reset password dialog.
|
|
* Extend block_manager to handle sidebar blocks. get_available has become get_available_admin_blocks, get_list becomes get_admin_list.
* Create new functions get_available_site_blocks which will look for gallery_block get_available_site_blocks.
* Refactor sidebar_blocks into a separate function and then call block_manager::get_html(site.sidebar). Convert image_block to use block management instead of theme::sidebar_blocks
* Change the block_manager api so that the theme is passed into the get method. convert info to the new sidebar block approach
* Convert the user module to use the new sidebar block structure. remove the installers for info and image_block modules.
* Convert tag and rss modules to the new sidebar framework. reset the version number to 1 for info and image_block modules.
* Change the get_html method to ignore empty blocks and change the individual handlers to return an empty string if no block is generated
* Add a warning message if no sidebar blocks are active and provide a link to the admin page that configures the sidebar.
|
|
gallery_event::$function first
* Refactor gallery.php to move site_menu, admin_menu, and context_menu to gallery_event.php
* Change Theme_View and Admin_view to call module::event("site_menu|admin_menu|context_menu"...)
|
|
|
|
Gallery_View::script/css to use gallery::find_file
|
|
active_site_theme. In addition check for the existence of THEMEPATH . instead of theme/
|
|
|
|
in the sidebar on movie page types.
|
|
API a little clearer. Write a test for it, too.
|
|
clean() and purify() the same.
No longer run a safe HTML string through the HTML purifier (since it's already marked as safe).
This also addresses the issue of calling purify() when no purifier is installed. In that case, we'd run clean() on a clean string (double HTML encoding).
If this approach doesn't work out, we can still modify the fallback code of purify() to check if the string is already clean before calling clean() instead of purify().
|
|
cleaner and we don't need to know about the module innards. Move the
config file over there too.
|
|
|
|
|
