| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
| |
Add new reset action to admin participant.
Also introduced action buttons (delete and reset).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
There were missing headers X-EcsSender and X-EcsReceiverCommunities
when accessing a resource through a POST on its queue mode or a
DELETE. This was caused by deleting the relationships between message
memberships before composing the headers. To prevent a double rendering
error it was also necessary to devide the show_render method.
|
| |
|
|
|
|
|
|
|
|
| |
Scenario:
Owner deletes his message for which he is concurrently a receiver
This should only be possible until he clears its receiver queue. Then
the next DELETE operation removes the message from ECS and also destroys
all other receiver references as it would be happened if the message
owner had not even addressed itself.
|
| |
|
|
| |
Further made some testcode for auths handling.
|
| |
|
|
|
| |
When creating authorization token the ECS only checks if exactly one of
the realm or url parameter is present.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now redirects are integrity secured by sha1 message digest.
A redirecting participant uses the /sys/auths resource realm
attribute to store a message digest over all relevant
redirect parameters (for details see [1]). The target
participant uses this message digest again and verifies the
integrity of the received redirect parameters
(Location-Header).
[1] see ECSA documentation at ECS->System resources->Auths
|
| |
|
|
|
|
|
| |
Introduced new exception names.
Moved code from message controller to message model.
New functional test for message controller testing forbidden deletion
(not a receiver or owner/sender) of a message.
|
| |
|
|
|
|
|
|
|
| |
If X-EcsReceiverMemberships or X-EcsReceiverCommunities were changed
following events will be generated:
* New receivers get "created" event.
* Removed receivers get "destroyed" event.
* Old receivers get "updated" events.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Function aliases in message model:
alias destroy_as_receiver destroy_unlinked_and_not_postrouted
alias destroy_as_sender destroy_
and code moved from messages_controller to message model.
I have also removed the :dependent => :destroy declaration from the
has_many :membership_messages declaration, because the deletion of the
membership_messages will be done explicitely from the message model when
deleting a message (via destroy_as_receive and destroy_as_sender). And
this deletion *must* depend on the calling participant.
|
| | |
|
| |
|
|
| |
It's a YAML configuration file for global ECS functionality.
|
| | |
|
| | |
|
| |
|
|
|
| |
The authorization resource (/sys/auths) functionality is now provided
through the standard application resource infrastructure.
|
| |
|
