I noticed today that the required dependencies doesn't include some that are stated on the module page. I added features and strongarm to the .info file:
name = Moodle SSO
description = Provides moodle authentication services
core = 7.x
package = Moodle Tools
version = 7.x-1.0
project = moodle_sso
dependencies[] = ctools
dependencies[] = libraries
dependencies[] = rest_server
dependencies[] = services
dependencies[] = user_revision
dependencies[] = features
dependencies[] = strongarm
features[ctools][] = services:services:3
features[ctools][] = views:views_default:3.0
features[features_api][] = api:2
features[services_endpoint][] = moodlesso
features[user_role][] = service-authentication
features_exclude[dependencies][features] = features
mtime = 1415685171
; Information added by Drupal.org packaging script on 2014-11-23
version = "7.x-1.x-dev"
core = "7.x"
project = "moodle_sso"
datestamp = "1416704284"| Comment | File | Size | Author |
|---|---|---|---|
| #12 | required_dependencies-2551101-12.patch | 454 bytes | nebel54 |
| #2 | moodle-sso.png | 15.6 KB | goose2000 |
Comments
Comment #2
goose2000 commentedComment #3
goose2000 commentedComment #4
alvar0hurtad0But....
does the module really needs features and strongarm to work?
Maybe features and strongarm are right options to deploy or reuse the configuration between several sites but in the require modules we should include only modules required to work.
Comment #5
netw3rker commentedYes, it does require them. It's strange that they aren't in the info file.
This module is in fact just a feature export of the config I used. and is shared/deployed to everyone that wants to do the same thing. Should you make changes to the settings tracked in here, you should use the features override module (https://www.drupal.org/project/features_override ) to track/save them.
Comment #6
goose2000 commentedTrying to understand why user_revision is needed ? Can you explain how that gets used?
Comment #7
netw3rker commentedUser revision is required to maintain the "highwater" mark for updates. the moodle service passes the last user_vid imported to Drupal to get any fresh updates and new users. This prevents the service from being overwhelmed by too many users, while syncing the process.
Comment #8
goose2000 commentedOkay, so if I am not using the user sync feature (not configured on moodle side) I may not need this?
Or put another way, if a user changed their last name, and then navigates to moodle, is the update coming from which table? users or user_revision table?
Thanks!
Comment #9
netw3rker commentedThat's true, though the view for this kinda depends on it, so you might have issues disabling it.
If I remember right, Lastname Is just an ordinary field, so it should show up in the view regardless of whether user reference is being used.
Comment #10
goose2000 commentedOh, never paid attention to that: /moodle-user-listings . Might be able to rework this view or just disable it, hmmm.
User: Name (name)
User: Active (status)
User: E-mail (email)
User: Uid (uid)
User revision: Vid (change_id)
Comment #11
goose2000 commentedWell this solved my problem(s)! , in case anyone is trying to meld Drupal, Commerce, Shibboleth, Moodle - disabling the sync view and disabling user_revision module cleared up my problem of missing emails in commerce orders for shibboleth type users. They now will get a receipt when they purchase a moodle course, whew!
I don't know why user_revision is messing up the shibboleth/drupal accounts, leaving them without email addresses.
And the basic SSO is still working fine without the sync/cron feature.
Comment #12
nebel54I can confirm that the installation does not work without features ;) The role service-authentication won't be created. I attached a patch which to ad the dependencies.
Comment #14
netw3rker commentedThanks Nebel54!
I've been meaning to get around to this! A patch always goes a long way to getting things done :)
I've committed this to the 1.x branch.
Comment #15
nebel54Thanks to you for providing the module :) I realized that the last few commits you did, have been committed directly to the master branch, so take care to get those changes back to the 1.x branch too before making changes the next time.