| Commit message (Collapse) | Author | Age | Lines |
... | |
|
|
|
|
| |
course_urls can now contain multiple URLs each with a
descriptive title attribute.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
A previously created event is now only reused (touching updated_at) when
it is the last on the participants event queue.
|
|
|
|
|
|
| |
A participant leaving a community will receive destroyed events for all
messages addressed to the leaving community and all messages addressed
directly at him which he has not yet deleted (still in his "queue").
|
|
|
|
|
| |
The postrouting after creating a new participant was removed and is now
done when entering a community.
|
|
|
|
|
| |
The property availability was just forgotten to pick up.
Avatar is a special property for StudIP Systems.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
If there is already a pending event describing a change of a message, don't
create another one. Instead only touch the "updated_at" attribute of the event.
In the participant show page there is now the "updated_at" time of the
event showed.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
This was needed because of "extremely critical security fixes".
|
|
|
|
|
| |
Now participants could create auth tokens with both "url" and "realm"
attributes (again).
|
| |
|
| |
|
|
|
|
|
|
| |
"basicData" -> "maxParticipants" removed
"parallelGroups" -> "id" type changed from integer to string
"parallelGroups" -> "title" removed (factored out to "basicData")
|
| |
|
|
|
|
| |
It's only an additional meta data. Use it or throw it away.
|
| |
|
|
|
|
| |
Ignoring case while sorting.
|
|
|
|
|
| |
List views of communities, organizations, participants and ressources
are now ordered.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This was done because we have decided that there are no burst
transmissions any more. Please see also email thread in cc-devel
starting with:
Date: Thu, 20 Dec 2012 18:54:25 +0100
Subject: resources and bursts
|
|
|
|
|
|
|
| |
Now you can call
curl .... -X POST https://server/sys/events/fifo?count=10
which returns a list of max. 10 events and concurrently deletes them
server side.
|
|
|
|
| |
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
|
|
|
|
| |
Now you get get the correct Content-Type header after resource creation.
|
| |
|
|
|
|
|
|
|
|
| |
When creating new participants and then postrouting messages i forgot to
check if rec_mids was empty. If so this means the message in question
must not be postrouted. Otherwise there will be thrown an
Ecs::MissingReceiverHeaderException exception and all further
possibly necessary postroutings will stop.
|
| |
|
| |
|
|
|
|
|
|
| |
There is now a rake ecs:gc_sys_auths task. This task deletes all
outtimed auths resources. Maybe this task should be called frequently
from a cron job.
|
|
|
|
|
| |
The memberships resource now returns also the pid (participant id) of
each participant.
|
| |
|
|
|
|
|
| |
When showing a community in the administration there is now a listing of
all joined participants.
|
| |
|
| |
|
| |
|