If multiple meeting are configured, /agenda queue should pick nearest one

[hanzei]

Hi, I need to know if this is expected behavior , If we set multiple Meeting days and then we add item to queue by /agenda queue Mytask. It Adds task to Saturday instead of Thursday.(even if its Monday on time of executing this command)

Issue created from a Mattermost message by @sanjay_demansol.

[maisnamraju]

@hanzei I'm looking into this. At first I thought it was because of DST but it's not because the days as far apart.

[maisnamrajusingh]

@hanzei I'm looking into this. At first I thought it was because of DST but it's not because the days as far apart.

@hanzei I tested this on multiple teams and it worked as expected. It moved to the next date in the settings. It easily gets confused though when you have multiple teams when you switch between multiple teams and move between their settings.
@mickmister sorry about this, but could you assign it to this account of mine that I am commenting from. I accidentally commented with my personal account

[mickmister]

It easily gets confused though when you have multiple teams when you switch between multiple teams and move between their settings.

@maisnamrajusingh Isn't /agenda queue a command that is processed on the server, and the settings are per-channel right? What is getting confused when you switch between teams, and what do you mean by "switch"?

[maisnamrajusingh]

@mickmister Sorry I meant switch between channels. For example user clicks on one channel sets the agenda and moves to another one that also has an agenda setting. I experienced this issue while testing as I was running the queue command on one channel whereas I had set the settings on another.

[maisnamrajusingh]

@mickmister were you able to replicate this ? I think the issue is invalid.

[mickmister]

@maisnamraju What are your test steps? Please format in this way:

• Set up agenda settings with two or more days
• ...

Expected:

Agenda item is queued for (whatever day happens to be closest)

Observed:

Agenda item is indeed queued for the expected day

---

You may need to test on different days of the week to see the behavior

[mickmister]

@maisnamraju Also, based on the issue description, it looks like @sanjaydemansol is the one that originally reported the issue in Mattermost. Maybe he has more context to provide for you

[maisnamrajusingh]

@sanjaydemansol can you test once again and see if the issue is replicated ?

[sanjaydemansol]

@maisnamraju ,I also had issues replicating same.

[maisnamrajusingh]

@maisnamraju ,I also had issues replicating same.

@sanjaydemansol do you mean you couldn't replicate it ? If thats the case we can close this.

[maisnamrajusingh]

@mickmister looks like we can close this.

[mickmister]

@DHaussermann Are you aware of the intended functionality when you don't supply the optional flag for the specific day you want to queue the item for? It seems there was undesired functionality of the plugin not queuing to the closest day, but now there is difficulty reproducing this issue. cc @sanjaydemansol @maisnamrajusingh

[sanjaydemansol]

@dipak-demansol any thoughts about this one?

[dipak-demansol]

@Hanze Your talking about this issue? (Pls see the video)

           by removing Sanjay code(From branch m-12 & mmt-12) i tested again and the same issue was Generated Again.

in this video when i created the Meeting for next week, it should be created for Monday but it created at Saturday.
https://user-images.githubusercontent.com/89907719/137910480-2130d639-cfc9-4a5c-8716-c7820a0d9f4c.mp4

[mickmister]

@DHaussermann @hanzei @dipak-demansol @sanjaydemansol

I'm a bit confused about the status of this. I think we need to figure the current behavior of the plugin and document it so we can have a source of truth. Maybe we should have some unit tests to assert the current behavior.

[catalintomai]

@sanjaydemansol - can you/your team add unit tests to Michael's comment? Thanks.

[mickmister]

Note that implementing unit tests will require mocking time.Now(), so any function we want to test will need to accept now *time.Time as a parameter, and we will be passing in hardcoded time values to assert different cases in the tests.

[sanjaydemansol]

@catalintomai sure, we will write.

[maisnamrajusingh]

@mickmister @hanzei I am taking over this one.