Issue 2519: Separate select constraint for allDay and non-allDay events
Status:  Duplicate
Merged:  issue 2475
Owner: ----
Closed:  Jun 2015
Reported by pap...@gmail.com, Jun 14, 2015
I think a more customizable selectConstraint would be a very nice feature to have. Here is what I thought of:

Currently the selectConstraint option's value is a single value, which is mandatory for all selections. I think it could be customized to have separate values for 'normal' events and for all day events.
I would use this to allow selecting allDay slots beyond the constraint of normal events (In my usecase, an allDay event represents a holiday request, while normal events represent working hours.)

I think this could be implemented in two ways:

1. array
The selectConstraint option should accept an array of two objects, each having two entries: 
    1. 'authority' with the value of either 'allDay' or 'normal' and 
    2. 'constraint' with the already used value types (id, 'businessHours', object)

2. object
The selectConstraint option should accept an object, just as it does now, but should check for the presence of an 'allDay' and/or a 'normal' key, indicating that this is a compound constraint. The values of each key could be the same ones that are currently accepted.


When making a selection, the code should decide whether the current selection is in an allDay slot or not, and then use the appropriate constraint value for checking.

I looked into the sources, but couldn't quite grasp the whole picture. I saw that the range checking function doesn't know whether the selection was started in an allDay slot or not. If this could be passed down to that function, I believe the rest shouldn't be too difficult to implement.

Jun 16, 2015
Project Member #1 adamrs...@gmail.com
i believe what you are asking for could be achieved by what  Issue 2475  is proposing. a function that can have logic that determines what the constraints are. merging...
Status: Duplicate
Mergedinto: 2475
Jun 17, 2015
#2 pap...@gmail.com
That was my first idea too, but when I tried to implement it, I wasn't quite sure about how it could fit into the current method. 
If you think that the function based version can be implemented, that would certainly be the more general approach!