Ray Morris

>  Maybe if someone can come up with a name that reflects what it actually does then things will make some more sense.
> Someone could go through and count but there's a whole bunch of things in there that aren't Settings (e.g. there's several links that are
> "actions" like "purge caches", "backup", "restore", "import", "export", "publish")

I think that's an important point, those things are actions, they do something, which implies one must be careful with them, and access to many of them will be limited.

Reports, on the other hand, show information and it's safe to "look around" by looking at reports.  From the very earliest days of the web, this distinction was clearly marked - you GET a web page but you POST a message.  "Changing things / making things" versus "seeing what someone did made" is a fundamental difference.

> It doesn't matter that they are not really settings, since there are plenty of other items in there that are not settings (e.g. backup).
> These are administrative functions

That's why I wouldn't want reports there.  They are mostly administrative functions, used by administrators, and are used to make changes to the system.  Reports are basically view only, they don't change the system, and are used by teachers and even students.  I don't think it makes sense to mix a report that a student might look it in with administrative functions.

Or as Martin Dougiamas put it "reports are not settings".

We will likely be doing the same thing a few months from now, so please follow up if you find some useful information.  I've done a lot of SSO, but not yet with Sharepoint, so I don't yet have anything specific to share, but:

"After 3 days searching the web without finding the answer (understandable for me !)"

Did you find some things that looked like they may be very useful to someone with a different background?  You may have found a perfect explanation which would make sense to me, for example, which I could use to make a module you could use.  Feel free to post any URLs and ask ask "what does this mean?"  (also feel free to email/msg me, as I might not see a reply here.)

What I can share based on implementing SSO systems before, and based on my background in cybersecurity, is that if you care about the system being at all secure, beware of any writing any custom code, especially for the core SSO handoff.  The bad guys know what the common mistakes are, so it's very, very easy to get that "wrong". For example, I can identify two or three vulnerabilties in code I've never seen just by looking at the filename.  (Example - any script called"download.php" virtually always includes the same three errors.)

If you decide that you do NOT care about security because in your case it doesn't matter if someone acesses an account, just be sure to  clearly mark that in several places so that your successor doesn't place high value data under the protection of your insecurity system.

I see that MOST modules don't follow that policy.  Is there any way to more actively encourage a policy to be followed?  Maybe because the rule itself is not consistent (some tables are supposed singular, others plural), developers don't notice that it's supposed to be consistently inconsistent?

Of the multi-word tables, exactly HALF and with an "s".  There are 259 multi-word tables. 130 end with an s.  So currently, a multiword table is equally likely to be singular as to be plural.  Most single word tables are singular, so it would be more accurate to say "all tables are singular" than to say "multiword names are plural".

Is your cron running?
Try refreshing http://yoursite.com/admin/cron.php three times.