| Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
first it makes sense that users and groups are a gallery requirement and belong in core. secondly, prepares the way for the Identity refactor.
|
|
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
|
|
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 from users, it could be in a ldap directory, it could be the gallery3 database, but the model could be wrapped in a control structure. So it was just easier to remove the restfulness and just call user::lookup instead.
|
|
drivers early in the process so the session deserialization works.
|
|
|
|
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.
|