Closed
Bug 1072524
Opened 10 years ago
Closed 7 years ago
The event search should include the "end range" date
Categories
(Mozilla Reps Graveyard :: reps.mozilla.org, task, P2)
Mozilla Reps Graveyard
reps.mozilla.org
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bob, Assigned: fossbalaji)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20140923004002
Steps to reproduce:
I searched an event by date using a custom period from 2014-09-19 to 2014-09-21
Actual results:
I didn't find this event : https://reps.mozilla.org/e/firefox-os-official-release-in-france/
No events happening the 21st were displayed.
Expected results:
Events happening on the 21st should be displayed.
Updated•10 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•7 years ago
|
Priority: -- → P2
Comment 2•7 years ago
|
||
(In reply to Balaji from comment #1)
> I would like to work on this bug.
That's great to hear! You can find the source code on GitHub (https://github.com/mozilla/remo) and the documentation to set it up here: http://remo.readthedocs.io/en/latest/installation-docker.html
Once you've set it up, please make sure that you have applied the patch from https://github.com/mozilla/remo/pull/1375 to make sure that you can login at 127.0.0.1:8000/admin with the created superuser. This is currently necessary and there is a bug on file for this, https://bugzilla.mozilla.org/show_bug.cgi?id=1386383. Once you've logged in at /admin you can load 127.0.0.1:8000 normally and you will be logged in.
Feel free to get back to me if you have any troubles setting it up for local development and I can try to help.
I will assign this bug here to you once there is a PR.
(In reply to Michael Kohler [:mkohler] from comment #2)
> (In reply to Balaji from comment #1)
> > I would like to work on this bug.
>
> That's great to hear! You can find the source code on GitHub
> (https://github.com/mozilla/remo) and the documentation to set it up here:
> http://remo.readthedocs.io/en/latest/installation-docker.html
>
> Once you've set it up, please make sure that you have applied the patch from
> https://github.com/mozilla/remo/pull/1375 to make sure that you can login at
> 127.0.0.1:8000/admin with the created superuser. This is currently necessary
> and there is a bug on file for this,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1386383. Once you've logged in
> at /admin you can load 127.0.0.1:8000 normally and you will be logged in.
>
> Feel free to get back to me if you have any troubles setting it up for local
> development and I can try to help.
>
> I will assign this bug here to you once there is a PR.
I have already done the setup of Remo codebase. I can able to runserver. Home page is fine.
I created super user but i can't able to login i'm getting this error
SuspiciousOperation at /admin/login/
Request object not found.
Request Method: POST
Request URL: http://127.0.0.1:8000/admin/login/
Django Version: 1.8.18
Exception Type: SuspiciousOperation
Exception Value:
Request object not found.
Comment 4•7 years ago
|
||
(In reply to Balaji from comment #3)
> (In reply to Michael Kohler [:mkohler] from comment #2)
> > (In reply to Balaji from comment #1)
> > > I would like to work on this bug.
> >
> > That's great to hear! You can find the source code on GitHub
> > (https://github.com/mozilla/remo) and the documentation to set it up here:
> > http://remo.readthedocs.io/en/latest/installation-docker.html
> >
> > Once you've set it up, please make sure that you have applied the patch from
> > https://github.com/mozilla/remo/pull/1375 to make sure that you can login at
> > 127.0.0.1:8000/admin with the created superuser. This is currently necessary
> > and there is a bug on file for this,
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1386383. Once you've logged in
> > at /admin you can load 127.0.0.1:8000 normally and you will be logged in.
> >
> > Feel free to get back to me if you have any troubles setting it up for local
> > development and I can try to help.
> >
> > I will assign this bug here to you once there is a PR.
>
>
> I have already done the setup of Remo codebase. I can able to runserver.
> Home page is fine.
>
> I created super user but i can't able to login i'm getting this error
> SuspiciousOperation at /admin/login/
>
> Request object not found.
>
> Request Method: POST
> Request URL: http://127.0.0.1:8000/admin/login/
> Django Version: 1.8.18
> Exception Type: SuspiciousOperation
> Exception Value:
>
> Request object not found.
Have you applied the patch from https://github.com/mozilla/remo/pull/1375 to your code base?
(In reply to Michael Kohler [:mkohler] from comment #4)
> (In reply to Balaji from comment #3)
> > (In reply to Michael Kohler [:mkohler] from comment #2)
> > > (In reply to Balaji from comment #1)
> > > > I would like to work on this bug.
> > >
> > > That's great to hear! You can find the source code on GitHub
> > > (https://github.com/mozilla/remo) and the documentation to set it up here:
> > > http://remo.readthedocs.io/en/latest/installation-docker.html
> > >
> > > Once you've set it up, please make sure that you have applied the patch from
> > > https://github.com/mozilla/remo/pull/1375 to make sure that you can login at
> > > 127.0.0.1:8000/admin with the created superuser. This is currently necessary
> > > and there is a bug on file for this,
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1386383. Once you've logged in
> > > at /admin you can load 127.0.0.1:8000 normally and you will be logged in.
> > >
> > > Feel free to get back to me if you have any troubles setting it up for local
> > > development and I can try to help.
> > >
> > > I will assign this bug here to you once there is a PR.
> >
> >
> > I have already done the setup of Remo codebase. I can able to runserver.
> > Home page is fine.
> >
> > I created super user but i can't able to login i'm getting this error
> > SuspiciousOperation at /admin/login/
> >
> > Request object not found.
> >
> > Request Method: POST
> > Request URL: http://127.0.0.1:8000/admin/login/
> > Django Version: 1.8.18
> > Exception Type: SuspiciousOperation
> > Exception Value:
> >
> > Request object not found.
>
> Have you applied the patch from https://github.com/mozilla/remo/pull/1375 to
> your code base?
Now got it working. I didn't apply the patch to get it work previously. I need to know this bug happens for past events or future events?
Comment 6•7 years ago
|
||
(In reply to Balaji from comment #5)
> Now got it working. I didn't apply the patch to get it work previously. I
> need to know this bug happens for past events or future events?
Seems to happen for future events as well: https://reps.mozilla.org/events/#/period/custom/start/2018-01-10/end/2018-01-11/
There should be at least https://reps.mozilla.org/e/activating-mozilla-workshop-1/ listed there.
I have found out that Event.objects.filter(start__gte='2018-01-07', end__lte='2017-01-12') . It won't pick the end date we are passing . suppose 12 is the end date then it will pick events upto 11. This is the thing that causes this bug.
Comment 8•7 years ago
|
||
(In reply to Balaji from comment #7)
> I have found out that Event.objects.filter(start__gte='2018-01-07',
> end__lte='2017-01-12') . It won't pick the end date we are passing . suppose
> 12 is the end date then it will pick events upto 11. This is the thing that
> causes this bug.
Good catch! I think '2017-01-12' is actually '2017-01-12 00:00'. I'm not sure how the date is stored, does it have timezone information? If so we probably could add the time to the query as well. What do you think?
(In reply to Michael Kohler [:mkohler] from comment #8)
> (In reply to Balaji from comment #7)
> > I have found out that Event.objects.filter(start__gte='2018-01-07',
> > end__lte='2017-01-12') . It won't pick the end date we are passing . suppose
> > 12 is the end date then it will pick events upto 11. This is the thing that
> > causes this bug.
>
> Good catch! I think '2017-01-12' is actually '2017-01-12 00:00'. I'm not
> sure how the date is stored, does it have timezone information? If so we
> probably could add the time to the query as well. What do you think?
Yes, Passing time solves this issue,
(e.x) I have one event on 11 in my local
e = Event.objects.filter(start__gte='2018-01-11 00:00:00', end__lte='2018-01-11 23:59:00')
this query returns one exactly . This solves this bug
In db also i checked it's a datetime field so along with datestring pass time also like this '2018-01-11 23:59:00'.
Comment 10•7 years ago
|
||
(In reply to Balaji from comment #9)
> (In reply to Michael Kohler [:mkohler] from comment #8)
> > Good catch! I think '2017-01-12' is actually '2017-01-12 00:00'. I'm not
> > sure how the date is stored, does it have timezone information? If so we
> > probably could add the time to the query as well. What do you think?
>
> Yes, Passing time solves this issue,
>
> (e.x) I have one event on 11 in my local
> e = Event.objects.filter(start__gte='2018-01-11 00:00:00',
> end__lte='2018-01-11 23:59:00')
>
> this query returns one exactly . This solves this bug
>
> In db also i checked it's a datetime field so along with datestring pass
> time also like this '2018-01-11 23:59:00'.
Great! Can we use 23:59:59? Even though it's not possible to set seconds on the portal for now, I think we should make sure that this wouldn't break if it was/will be possible at some point.
Once that is done, can you file a pull request against the repository? Please without the initially applied patch to make it work, as this is already covered in another pull request. You could checkout master, do a new branch and cherry-pick all your commits into that branch and use that branch to do a PR. Feel free to ask if you get stuck :)
Assignee | ||
Comment 11•7 years ago
|
||
(In reply to Michael Kohler [:mkohler] from comment #10)
> (In reply to Balaji from comment #9)
> > (In reply to Michael Kohler [:mkohler] from comment #8)
> > > Good catch! I think '2017-01-12' is actually '2017-01-12 00:00'. I'm not
> > > sure how the date is stored, does it have timezone information? If so we
> > > probably could add the time to the query as well. What do you think?
> >
> > Yes, Passing time solves this issue,
> >
> > (e.x) I have one event on 11 in my local
> > e = Event.objects.filter(start__gte='2018-01-11 00:00:00',
> > end__lte='2018-01-11 23:59:00')
> >
> > this query returns one exactly . This solves this bug
> >
> > In db also i checked it's a datetime field so along with datestring pass
> > time also like this '2018-01-11 23:59:00'.
>
> Great! Can we use 23:59:59? Even though it's not possible to set seconds on
> the portal for now, I think we should make sure that this wouldn't break if
> it was/will be possible at some point.
>
> Once that is done, can you file a pull request against the repository?
> Please without the initially applied patch to make it work, as this is
> already covered in another pull request. You could checkout master, do a new
> branch and cherry-pick all your commits into that branch and use that branch
> to do a PR. Feel free to ask if you get stuck :)
Ok i will add time in backend and create a pull request . Thanks.
Assignee | ||
Comment 12•7 years ago
|
||
I have made a pull request https://github.com/mozilla/remo/pull/1417
Updated•7 years ago
|
Assignee: nobody → fossbalaji
Status: NEW → ASSIGNED
Assignee | ||
Comment 13•7 years ago
|
||
Hi,
Anything else can be done for this pull request https://github.com/mozilla/remo/pull/1417 ?
Comment 14•7 years ago
|
||
Commits pushed to master at https://github.com/mozilla/remo
https://github.com/mozilla/remo/commit/96af7eba127816f9f7f794ffa309d00e614aea6e
fix bug 1072524: The event search should include the end range date
https://github.com/mozilla/remo/commit/4319eda9e6bfefcb4f14bd0b7ab2d180c19a842a
Merge pull request #1428 from akatsoulas/event-search-datetime
fix bug 1072524: The event search should include the end range date
Updated•7 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•4 years ago
|
Product: Mozilla Reps → Mozilla Reps Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•