aboutsummaryrefslogtreecommitdiff
path: root/config
Commit message (Collapse)AuthorAgeLines
* Secure sessions.Heiko Bernloehr2016-01-27-1/+2
|
* Standard rails stack minus ParamsParser.Heiko Bernloehr2016-01-27-24/+5
|
* Add reset action button.Heiko Bernloehr2016-01-27-2/+4
| | | | | Add new reset action to admin participant. Also introduced action buttons (delete and reset).
* Logging-Observer.Heiko Bernloehr2016-01-27-0/+1
| | | | Logging event creations.
* Disable session cookies.Heiko Bernloehr2016-01-27-1/+0
|
* WIP: subparticipants.Heiko Bernloehr2016-01-27-2/+5
|
* New resource /sys/configsHeiko Bernloehr2014-05-07-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Every participant could GET and POST to this resource. A GET might show this: curl ... -H 'Content-Type: application/json' \ -X GET https://ecs.host.com/sys/configs { "participant_events": "true", "resource_events": { "/campusconnect/glossaries": true, "/campusconnect/course_urls": true, "/campusconnect/course_members": true, "/campusconnect/wikis": true, "/campusconnect/directory_trees": true, "/campusconnect/learningmodules": true, "/campusconnect/groups": true, "/campusconnect/categories": true, "/campusconnect/courselinks": true, "/campusconnect/organisation_units": true, "/campusconnect/files": true, "/campusconnect/terms": true, "/campusconnect/courses": true, "/sys/auths": false }, "selfrouting": "false" } Only if participant_events and the appropriate resource_events are true, you will get an event. It's also possible to set the two attributes participant_events and selfrouting. Just make a POST such as: curl ... -H 'Content-Type: application/json' -X -X POST \ -d '{"participant_events":true}' https://ecs.host.com/sys/configs or curl ... -H 'Content-Type: application/json' -X -X POST \ -d '{"selfrouting":false}' https://ecs.host.com/sys/configs or curl ... -H 'Content-Type: application/json' -X -X POST \ -d '{"selfrouting":false, "participant_events":true}' \ https://ecs.host.com/sys/configs As you see, just set the attribute you want to set and make a POST. You don't have to provide a receiver header, because the receiver is implicitely the ECS.
* Turn on/off events by participants.Heiko Bernloehr2014-05-07-0/+2
| | | | | | | Up to now events could be turned on and off by resources. To turn on events you still have to do it by resource but have additionally the possibility to control it by participant. Only if both switches are on, the participant will get events generated through the resource.
* Updated rails to 2.3.18Heiko Bernloehr2013-06-01-1/+1
|
* New logger format.Heiko Bernloehr2013-02-07-3/+13
|
* Updated rails to 2.3.16Heiko Bernloehr2013-02-01-1/+1
| | | | This was needed because of "extremely critical security fixes".
* Undo ECS initialization modifications.Heiko Bernloehr2012-06-25-32/+0
| | | | Initialize code don't have access to model objects.
* Modified ECS initialization.Heiko Bernloehr2012-06-25-1/+31
|
* New ECS configuration file introduced.Heiko Bernloehr2012-06-22-0/+16
| | | | It's a YAML configuration file for global ECS functionality.
* Changed to rails 2.4.14Heiko Bernloehr2012-02-15-35/+7
|
* Threads required for rvm.Heiko Bernloehr2011-12-31-0/+1
|
* Removed subresource "receivers".Heiko Bernloehr2011-05-11-1/+1
| | | | | | | | | | Please use the subresource "details", e.g. From the viewpoint of a sender you may use: instead of curl .... -X GET https://server/<namespace>/<name>/<id>/receivers use curl .... -H 'X-EcsQueryStrings: sender=true' -X GET https://server/<namespace>/<name>/<id>/details
* New collection subresource "details" added.Heiko Bernloehr2011-03-19-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now it's possible to ask for detailed (meta) information of a list resource. All querystrings supported my normal list resources could be used. Only the original sender can do that: curl .... -X GET https://server/<namespace>/<name>/details You will get back a list of member subresource "details" representations: [ { "receivers": [ { "itsyou": true, "mid": 1, "cid": 2 }, { "itsyou": false, "mid": 2, "cid": 2 } ], "senders": [ { "mid": 1 }, { "mid": 1 } ], "url": "courselinks/10", "content_type": "application/json" }, ... ]
* New member subresource "details" added.Heiko Bernloehr2011-03-18-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now it's possible to ask for detailed (meta) information of a posted message. Only the original sender can do that: curl .... -X GET https://server/<namespace>/<name>/<id>/details You will get back something like this: { "receivers": [ { "itsyou": true, "mid": 1, "cid": 2 }, { "itsyou": false, "mid": 2, "cid": 2 } ], "senders": [ 1, 1 ], "content_type": "application/json" } The "receivers" and "senders" have corresponding arrays: The first array entry in "senders" has been addressed the first array entry of "receivers" and so on.
* New subresource "receivers" added.Heiko Bernloehr2011-03-10-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Now it's possible to ask for the addressed receivers of a posted message: curl .... -X GET https://server/<namespace>/<name>/<id>/receivers You will get back an array of receiver memberships, e.g. [ { "pid": 3, "itsyou": false, "cid": 2, "mid": 2 } ] pid: participant id cid: community id mid: membership id itsyou: true if the item belongs to you
* System resources moved to sys namespace.Heiko Bernloehr2011-03-03-0/+4
| | | | | | | | | | | | The system resources /events, /memberships and /auths are now called through the sys namesapce: /sys/events /sys/memberships /sys/auths The old syntax is now tagged as deprecated. All participants are solicited to change their calling.
* Bundler configuration.Heiko Bernloehr2011-02-13-3/+35
|
* Initial commit.Heiko Bernloehr2011-01-31-0/+675