| Age | Commit message (Collapse) | Author |
|---|
|
changing providers.
|
|
in a helper class.
|
|
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
|
|
installed. This is mostly for the unit_tests as when the gallery3 installer is used, the user module is activated by default.
|
|
administrator user.
|
|
provider is the user module.
|
|
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
|
|
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.
|
|
|
|
first it makes sense that users and groups are a gallery requirement and belong in core. secondly, prepares the way for the Identity refactor.
|
|
|
|
gallery module
|
|
|
|
gallery module.
|
|
the notifications to use user::get_user_list instead of accessing the table directly.
|
|
user::lookup_by_name and user_lookup API methods.
Convert the Admin_User controller
Convert the login and password change controller
Change the item model to call user::lookup to get the owner.
On the log model, delete the relationship between the log and user table, and replace with a
call to user::lookup
(cherry picked from commit 194cc3b27a73afe5119da9f09407c1e068dc6fa3)
Create the get_user_list, lookup_by_name, lookup_by_hash and get_group_list api functions
|
|
our approach to restfulness is that it assumes that the resource will be found in the gallery database. It may well be there, but in the case of using plugable drivers for users management, there are no guarantees that it is in our database or it could be in a ldap directory. So it was just easier to remove the restfulness and just call user::lookup instead.
(cherry picked from commit b3211cb2a8282556d410c91771baeb764d47ed10)
|
|
|
|
shared images from wind to lib. Deleted unused images in the admin_wind. This will likely break a few ajax features.
|
|
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.
|
|
instead of HTML entities.
|
|
Use « and » in the << none >> text.
|
|
and check the browser's / OS' locale preferences.
Ticket 582.
|
|
call.
|
|
the system's default table specification. Fixes ticket #597.
|
|
login page itself.
Signed-off-by: Bharat Mediratta <bharat@menalto.com>
|
|
1) We don't need to loop over the elements to bind the event handler.
2) Just include gallery.panel.js for all the admin pages.
Signed-off-by: Tim Almdal <tnalmdal@shaw.ca>
|
|
|
|
This is the first step towards having a simple, lightweight and
unified API for module interaction.
|
|
|
|
user_add_form_admin admin adding a user
user_edit_form_admin admin editing a user
user_add_form_admin_completed successfully added a user (admin)
user_edit_form user editing their own settings
user_edit_form_completed successfully edited a user (admin and user editing own settings)
|
|
theme. Because the theme comes first, this means that themes can
override any module resources, at the cost that we no longer have
namespacing for JS and CSS files.
The only file getting used outside of this model is
themes/default/screen.css which is used in the admin theme. I fixed
that by copying screen.css into admin_default and renaming its
screen.css to admin_screen.css. I also copied over all the images
that it was referencing.
Fixes tickets #48 and #539.
Theme API changes:
- theme_script(), theme_url() and theme_css() are no longer needed
- script(), url() and css() now refer to the first matching asset in
the module load path, where gallery3/lib is at the end of the path
|
|
Fixes ticket #194
|
|
related events from within the model handling code. The only
exception to this currently is item_created which is challenging
because we have to save the item using ORM_MPTT::add_to_parent()
before the object itself is fully set up. When we get that down to
one call to save() we can publish that event from within the model
also.
|
|
issue in translation server)
|
|
|
|
Add xxx_installer::upgrade($version) method so that upgrade stanzas
are separate from install stanzas. In the old code, to do an upgrade
meant that you had to re-evolve everything from the initial install
because we'd step through each version's changes. But what we really
want is for the initial install to start off in the perfect initial
state, and the upgrades to do the work behind the scenes. So now the
install() function gets things set up properly the first time, and the
upgrade() function does any work to catch you up to the latest code.
See gallery_installer.php for a good example.
|
|
immediately after install. Fixes ticket #323.
|
|
Install: <module>_installer::install() is called, any necessary tables
are created.
Activate: <module>_installer::activate() is called. Module
controllers are routable, helpers are accessible, etc. The module is
in use.
Deactivate: <module>_installer::deactivate() is called. Module code
is not accessible or routable. Module is *not* in use, but its tables
are still around.
Uninstall: <module>_installer::uninstall() is called. Module is
completely removed from the database.
Admin > Modules will install and activate modules, but will only
deactivate (will NOT uninstall modules).
|
|
|
|
|
|
|
|
of checking G1/G2 techniquew first).
|
|
|
|
consistency. No 3rd party libs in "libraries", at least for now.
|
|
|
