jbee / collaborate Goto Github PK

The XP gained by resolving tasks should be dynamic.
A task immediately resolved does not provide much (if any) XP.
A "old" task however should provide maximum XP.
It is important to use time as time cannot manipulated by users while multiple user accounts always could be controlled by same bot (so multiple users involved is no indication of "real" tasks).

It also has to be tracked in what products a user has gained XP.
XP should only apply in those projects. Maybe this should even be a mapping.
This prevents users from "mining XP" in their own products in order to manipulate other products.

As the tracker should allow for open and anonymous cooperation it has to be able to deal with spam.
The basic concept is to only allow little accumulation of unverified content.
At the moment this is mostly regulated using time as a protection. Within a span of time only X (unconfirmed) changes may be issued. This has the advantage of unblocking itself automatically as time progresses. But it also open for a long-term avenue of attack. Also it requires some "locks" that make persistence more complicated that desirable.

Maybe a simpler approach is better where there are fix limits for each type of unconfirmed content (N product, M versions, ...) and a appropriate member has to reject or confirm the change.
However, this will not protect against bot users that go mad.
Is there a better way to keep this in control without creating problems for persistence?

Problem:
Every change that introduces new entities has to be limited in some way so that mad users (registered or not) cannot flood the system with litter. This are: products, areas, versions, users, polls, tasks, sites.

One approach could be to accumulate "change points" for each user. All anonymous users share one user account (of user "anonymous"). Thereby the "update" is local to the user acting what removes need to synchronize or lock users actions against each other. However, there is still the problem of registering many users in order to do lots of silly things.

Another idea: connect this to user's XP. Provide initial XP that is enough to create a product and an area.
Resolving tasks gives XP. If resolving tasks fast gives less XP than it needs to create tasks one cannot spin up a wheel out of control no matter how many users are involved. (this idea was flawed)

It would be good to be able to see the top 10 user for an output or area.
Problem is how/where to store the score. Most likely in the User is the best.

Currently the update methods in EntityManager are directly accessible.
This makes it hard (or impossible) to know what updates are part of the same change-set.

There should be clear stages

open => update... => commit
open => update... => cancel

On the other hand the whole EM might see the DB in one fix state.
In that case just commit and cancel methods are missing.

However it is undesirable to force read/write to always be consistent.
Reads can see latest as long as writes use opt-locking.