Need many lockings for different, non-overlapping time intervals

[ziweidream]

We need a user to be able to lock his/her tokens once for a week, and be able to lock for different weeks, so locking is like a weekly recurring event, although each week is optional for a user. But in TimeLockManager.sol, a user can only lock his/her tokens once, and never be able to lock again for another period, due to this line of code(line 43) in function lock(..)

require(timeIntervals[_owner].end == 0, ERROR_ALREADY_LOCKED);

https://github.com/aragon/staking/blob/master/contracts/locking/TimeLockManager.sol#L43

Would you please enable the option of a user being able to lock many times for different, non-overlapping time intervals? For example, maybe the timeIntervals[_owner].end can be set as 0 again after legitimate unlock and/or after now > timeIntervals[_owner].end?

Or simply allow locking after now > > timeIntervals[_owner].end:
require(timeIntervals[_owner].end == 0 || now > timeIntervals[_owner].end , ERROR_ALREADY_LOCKED);

Or, alternatively, a user can have many TimeInterval instead of just one TimeInterval (but this may be unnecessarily complicated since time flows only one way):
mapping (address => (uint256 => TimeInterval)) internal timeIntervals;

Thanks.

[innovator256]

@bingen and @luisivan As mentioned by my colleague @ziweidream above, we are testing your staking app functionality within our kittieFIGHT contract system to be deployed to main net in a few days. And we are in need of arbitrary locking and unlocking mechanism without being limited to a specific time based locking ? for example you couple have an alternate locking mechanism like :

function Arbitarylock(IStakingLocking _staking, address _owner, uint256 _amount, uint256 _unit)

then the required internal checks to lock would be based lock/unlock status only
Which is not time dependent, but according to user needs.

[sohkai]

Hi @innovator256 @ziweidream, your use case may be best served by forking this repo and making your own changes.

Note that the contents of this repo are not yet audited yet, and we would not recommend putting live funds at risk through it yet.