Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decouple pickup/event and store/place #1128

Closed
brnsolikyl opened this issue Nov 7, 2018 · 3 comments
Closed

Decouple pickup/event and store/place #1128

brnsolikyl opened this issue Nov 7, 2018 · 3 comments
Labels

Comments

@brnsolikyl
Copy link
Contributor

Related to #1127

Just wondering how big of a task would it be to decouple a pickup/event from a store/place and if it's worth the shot? As I understand, the way it works now is that a pickup is always connected to a store. The pickup/event needs to be created after a store/place is created. However, if we make it possible to decouple event and place, I believe it would open up new possibilities for users and improve the flow (for example, it would become easier to create a one-time event in which the place is not really a very relevant information and does not need to be saved on the list of stores/places).

To put it another way, the flow at the moment is:

  • Create a store/place -> Create a pickup/event

It would become:

  • Create a pickup/event -> (and if desired) Create or select a store/place

Possible problem:

  • People not attentive when creating an pickup/event that there is already a store/place that would correspond to it, so the pickup/event would not be visible on the store/place page nor would the feedback and stats be connected to it.
@tiltec
Copy link
Member

tiltec commented Mar 27, 2019

Some time passed, what do you think about it nowadays @brnsolikyl ?

Where should decoupled events get listed? On the wall and on the group pickups page? Are they some kind of "group event" then?

Technical points!
Sometimes event behavior depends on properties of place they are part of:

  • pickup series are only updated if the store is active
  • the store contains the setting how many weeks in advance pickups should be generated

If we decide to decouple events, we would either

  • add a lot of ifs to the code (thereby increasing complexity)
  • or remove those dependencies, making Karrot a bit harder to use (e.g. pickup series need to be disabled explicitly when archiving a store, each pickup series would need their own "weeks in advance" setting

We might need to touch these parts of the code anyways for the generalization, so let's see what options we have there.

@brnsolikyl
Copy link
Contributor Author

After some progress on thinking the generalization #1127 I think that decoupling event from place can be desirable depending on the type of event and not generally. For example, pickups as a type of event really needs to be tied to a place, and also meetings, if they are not online.

For certain tasks it might be the case that it's better to not set a place, for example if there is a task to call store managers. But that's a very hypothetical case that implies that Karrot would be used more broadly as a kind of task manager for groups.

@github-actions
Copy link

This issue is marked as stale because it has not had any activity for 90 days, remove the stale label or add a comment on it, otherwise it will be automatically closed in 7 days. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants