Yep OK I think we are basically in agreement;
The shift pattern will influence the resource's displayed availability field on creation / when no "override" has been provided.
However, once you "override" that availability value for a resource then that override value is used (and the shift-pattern becomes irrelevant for
that resource).
All relatively clear then!
--
The only bit I 'disagree' with is this
another_martink wrote:
As far As I can see XOGing a different value and changing the value on resource properties do the same thing: Both mess your system and neither should be done.
As long as we understand what is happening (as above) then there is no problem in affecting the "availability" as a single value - I would argue that having a single "working days" calendar and then managing individual resources hours-per-day at resource level is no more or less complex than having several calendar's with differing shift-patterns that represent the hours-per-day. It comes down to a functional/deployment choice really. The whole area of "shift-patterns" does also strike me as obsoleted functionality from earlier versions/products though - is it used anywhere else in the application at all?
( My experience comes from a system where we have always provided / populated that single "daily availability" value for all resource via a XOG-interface from an external system, so I have never had to 'fight' the shift-patterns. i.e. all of my resources have had "override" availability applied - the field is on-screen in the resource-create view as well so gets manually populated in a manual resource creation thus shift-patterns are ignored for all. But that is the functional choice made when that system/interfaces were set up (not by me))
--
So in Joan's use-case, I do agree that one solution would be to create a new calendar/shift-pattern and then associate the relevant resources with that calendar (however that would only work if the availability for the resource had never been "overridden" I think?) . Another solution would be to update (override) the resource's availability (through the screen or through XOG) - its just a functional choice what to do; pros and cons (functionally) of both.
EDIT : I'll just revise my statement slightly after reading your PDF and that other thread (which I should have done a lot earlier!) ;
The shift pattern will influence the resource's displayed availability field on creation / when no "override" has been provided.
However, once you "override" that availability value for a resource then that override value is used (and the shift-pattern becomes irrelevant for that resource).
If you subsequently change the resource's calendar, then the override will be also be changed pro-rata to the new calendar's shifts.