| Commit message (Collapse) | Author | Age | Lines |
|\ |
|
| |
| |
| |
| | |
This script could/should be called by crontab.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
There is no Message::destroy_msg(msg) method any more. So I changed it to
msg.destroy_as_sender.
|
| |
| |
| |
| |
| | |
There is no Message::destroy_msg(msg) method any more. So I changed it to
msg.destroy_as_sender.
|
| |
| |
| |
| | |
Print number of deleted messages when garbage collect old exercises.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Exercises Filter-Plugin.
This filter masquerades the response of an request to
/numlab/exercises/<id>. With a query string the request only contain
toplevel properties with simple string type. For now these toplevel
properties are:
* postTime
* identifier
* comment
* name
* description
* environment
The querystring parameter is known as: properties. You're allowed to
note multiple toplevel properties, spaced by comma. Please be patient
not to include any spaces in the list.
Working ressource notations are:
http://ecs.uni-stuttgart.de/numlab/exercises/27?properties=name
http://ecs.uni-stuttgart.de/numlab/exercises/27?properties=name,description
http://ecs.uni-stuttgart.de/numlab/exercises/27?properties=name,description,comment,identifier
Problematic/forbidden notations are:
http://ecs.uni-stuttgart.de/numlab/exercises/27?properties= name
http://ecs.uni-stuttgart.de/numlab/exercises/27?properties=name ,description
http://ecs.uni-stuttgart.de/numlab/exercises/27?properties =name,description,comment , identifier
|
| |
| |
| |
| |
| | |
Delete old exercises. You have to edit the task file to change the time from
when the exercises will be deleted.
|
| |
| |
| |
| |
| | |
Delete old results. You have to edit the task file to change the time from when
the results will be deleted.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using following SELECT (created from a Message.fifo_lifo_rest call) on a VIP
devel database always hangs for several seconds:
SELECT messages.id FROM "messages" INNER JOIN "ressources" ON "ressources".id = "messages".ressource_id INNER JOIN "membership_messages" ON membership_messages.message_id = messages.id INNER JOIN "memberships" ON "memberships".id = "membership_messages".membership_id INNER JOIN "participants" ON "participants".id = "memberships".participant_id WHERE ("ressources"."namespace" = 'numlab' AND "ressources"."ressource" = 'results' AND "participants"."id" = 3) ORDER BY messages.id ASC LIMIT 1;
When omitting "LIMIT 1" all went well. Also when setting LIMIT greater than 5.
If using another resource, e.g. solutions or exercises, all went well too. Also
when using DESC instead of ASC.
I really don't know why Postgres responds like that. So I made a workaround, by
selecting the first element from the list in ruby, knowing that this solution
is much slower than using LIMIT 1 at database level, but only when the list is
not empty.
|
| |
|
| |
|
|
|
|
|
| |
Add new reset action to admin participant.
Also introduced action buttons (delete and reset).
|
| |
|
|
|
|
|
|
|
|
| |
When creating a resource ECS returns a location header in its http
response. If the server port differs from 80 or 443 the server port will
be included in the location header, e.g.:
Location: http://localhost:8080/numlab/evaluations/1044199
|
|
|
|
| |
Changed filter class method to an instance method.
|
|
|
|
| |
Logging event creations.
|
|
|
|
| |
Forgot to commit the db migration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Participants in /sys/mebmberships representation are now tagged with
their appropriate participant type:
main: mainparticipant
sub: subparticipant
anonym: anonymous participant
e.g.
[
{
"community": {
"name": "public",
"description": "For anonymous participants.",
"cid": 1
},
"participants": [
{
"pid": 2,
--> "type": "main",
"name": "Computation client",
"itsyou": true,
"description": "Computation client of NumLab service.",
"org": {
"abbr": "S",
"name": "Universität Stuttgart"
},
"mid": 1,
"email": "rudlof@rus.uni-stuttgart.de",
"dns": "nfldevvipecs.rus.uni-stuttgart.de"
},
...
This feature needs a database migration.
|
|
|
|
| |
The default filter for /sys/memberships is now mainparticipants=true
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now it's possible to filter /sys/memberships resource:
* /sys/memberships?mainparticipants=true
You get only memberships concerning mainparticipants (MPs). MPs are
participants which have to be registered/configured by hand over the
ECS Webinterface.
* /sys/memberships?subparticipants=true
You get only memberships concerning/containing subparticipants (SPs). SPs are
participants which are created dynamically by MPs.
* /sys/memberships?anonymous=true
You get only memberships concerning/containing anonymous participants (APs).
The creation of new APs automatically takes place
by every call to an ECS resource if the calling participant didn’t set
X-EcsAuthId or Cookie header. AP-Handling has to be activated
explicitly in the ECS configuration.
* /sys/memberships?all=true
You get all available memberships irrespectively of their type.
The default filter is set to "mainparticipants=true".
The filter could also be specified by a HTTP variable e.g.:
curl ... -H 'X-EcsQueryStrings: mainparticipants=true' http://.../sys/memberships
|
|
|
|
|
| |
Changed extended associations in community model to named scopes in
participant model.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For easier communication of a participant with its newly created
subparticipant I exchanged the community element with a memberships
element. Now the creating participant gets all necessary information of
its subparticipant to start communication right after creation. The
memberships element has the same structure as a resource representation
of /sys/memberships but there is only the newly created
subparticipant listed in the participants array (itsyou=true). The
/sys/memberships representation lists *all* participants (and
subparticipants) joining the same community.
After creating a subparticipant:
curl ... -H 'Content-Type: application/json' \
-X POST -d '{"realm":"tux","communities":["stephan","public"]}' \
https://.../sys/subparticipants
you get something like this as answer (example):
{
"description": "Created from \"Teacher client\" (pid:3)",
"community_selfrouting": false,
"realm": "tux",
"auth_ids": [
{
"desc": "Randomized authid",
"auth_id": "06e9506fa723b2353cbe4acc32a9a568"
}
],
"memberships": [
{
"participants": [
{
"email": "xaver@freeit.de",
"org": {
"abbr": "S",
"name": "Development FreeIT Suttgart"
},
"name": "Subparticipant (id:67)",
"mid": 190100,
"dns": "N/A",
"description": "Created from \"Teacher client\" (pid:3)",
"pid": 190376,
"itsyou": true
}
],
"community": {
"cid": 2,
"name": "devel",
"description": "Devel test community."
}
},
{
"participants": [
{
"email": "xaver@FreeIT.de",
"org": {
"abbr": "S",
"name": "Development FreeIT Stuttgart"
},
"name": "Subparticipant (id:67)",
"mid": 190101,
"dns": "N/A",
"description": "Created from \"Teacher client\" (pid:3)",
"pid": 190376,
"itsyou": true
}
],
"community": {
"cid": 1,
"name": "public",
"description": "For anonymous participants."
}
}
],
"name": "Subparticipant (id:67)",
"email": "xaver@freeit.de",
"events": true,
"dns": "N/A"
}
|
|
|
|
|
|
| |
It's not any more possible to use arbitrary authentication values in the Cookie
header. Now it's only possible to use anonymous cookie values in anomymous
Cookie header and subparticipant cookie values in subparticipant Cookie header.
|
|
|
|
|
| |
Moved authentication code for "authenticated participants" at the end of the
authentication queue again.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
When a participant wants to create a subparticipant and provides some
communities which this subparticipant should belong to, he is only allowed to
provide communities he joins on its own.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Moved authentication code into functions.
|
|
|
| |
To tag the ticket type we're now now postfixing ticket title.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Default ttl value for subparticipants being deleted is 10 days. Please
adjust to your needs directly in the source task file.
|
| |
|
| |
|
|
|
|
| |
Moved code from MembershipsController to Membership model.
|