Swap Meet Proposal Acceptance Behavior

There are a number of distinct situations related to proposals including some where immediate application of the proposal is possible and some where it is not:

Proposals directed to specific users

1.1 Proposals that can have only 1 outcome (i.e., give or take with a single proposal recipient involved, splits with no unassigned time fragment,and trade where only 2 shifts are involved)

In this case, the proposal can be executed immediately when the recipient accepts. This is the current behavior that applies to your group for proposals in this category.

1.2 Proposals that can have more than 1 outcome (i.e., give or take proposed to multiple recipients, trade where the offered shift is proposed to multiple recipients). In addition, when a provider defines multiple proposals that involve the same shifts (e.g., a give proposal and a trade proposal for the same shift), each of these proposals is considered under this category of multiple outcomes possible, even if each of the individual proposal is to a single recipient.

In this case, the proposal *cannot* be executed immediately when a recipient accepts the proposal. The provider who created the proposal has to accept (or deny) the responses they get from providers on the receiving end of the proposal. This behavior is implemented to avoid having the system make an arbitrary choice as to which proposal should be applied to the schedule when the originating provider indicated they wanted to consider several distinct options.

Proposals not directed to specific users (i.e., proposals available in the swap meet). Since these proposals are in the swap meet, multiple providers can respond to them.

2.1 Proposals of a single type (e.g., a give or -- exclusively -- a trade) This situation corresponds to the case you referenced in your communication to us. The current behavior is to require the originator of the proposal to accept the response they prefer. They can also withdraw the proposal at any time, even if there are pending responses. As already stated, we can change the behavior for your group such that the proposal is converted into a schedule change upon first acceptance by a provider. The only loss of flexibility that providers will incur is the inability to withdraw the proposal after it has been responded to positively.

2.2 Proposal with multiple types (e.g., a give or -- inclusively -- a trade)

In this case, the originator of the proposals must accept a response before the proposal becomes effective, similarly to case 1.2. This requirement is in place for the same reason indicated in 1.2 above (i.e., avoid making an arbitrary choice when multiple options are specified by the provider defining the proposals).

3. Mixed proposals (i.e., proposal submitted to both specific individuals and the swap meet).

For such proposal, acceptance of positive response(s) by the originator of the proposal is required, for the reason stated above in sections 1.2 and 2.2.

The proposal module in ByteBloc strives to provide maximum flexibility to providers such that they can define multiple proposals for a given shift and choose the change that will be best for them.

We sincerely appreciate your feedback and are committed to making ByteBloc the best and most flexible schedule management system for your group.