When putting in admin days available to work, calander to book is off by a row. #172
Comments
|
Hi @nadermx, can you provide screenshot ? I tried to reproduce the bug describe, but was unable to do so. |
|
Sure, I have a few. |
|
Okay, just saw that the staff memeber didn't have in the user profile a first and last name, that fixes the name issue, but the day issue on the map is still off. |
|
I was checking the views.py in the appointment folder, and I think it has to do with either not saving the working days timezone specific, or not calling the days timzone specific. Been messing with it to no avail thus far |
|
Did a pull request with the fix #174 |
|
Hi @nadermx, I will have a look. Thanks |
The homepage is a screenshot from a project that I use the package in, and no, it's not set from monday - friday but from sunday to thursday. I can't seem to find out why it behaves differently when you're running it...But I'll investigate from your pull request. |
As mentioned by @deronnax, I need to use the username a little bit more than just first and last name. I will fix that in a coming release. |
|
Interesting. On a fresh install when I tried to make as shown on
screenshots, it allowed it Tuesday. I ha e Django timezone set to
America/Mexico_city
…On Thu, Apr 4, 2024, 6:28 PM Adams Pierre David ***@***.***> wrote:
And in your home page example it also shows days available as Sunday
through thursday, altough I'm sure you have it set as monday-friday?
The homepage is a screenshot from a project that I use the package in, and
no, it's not set from monday - friday but from sunday to thursday. I can't
seem to find out why it behaves differently when you're running it...But
I'll investigate from your pull request.
—
Reply to this email directly, view it on GitHub
<#172 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABYACXADCXYUJYTC5AI3CS3Y3XV33AVCNFSM6AAAAABFS3UJACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZYGQ4TMMBWGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Noted. It shouldn't be that way indeed. |
|
Hi @nadermx, Sorry for the late response to your issue. I've been busy with work and other things. Would you be willing to show me your settings file and a screenshot of the error where the timezone is not updating, resulting in the incorrect day? |
I fixed that in the latest release
Unfortunately, you didn't run the test files. |
|
Hi @nadermx, I've reviewed and tested your changes. Unfortunately, it introduces a mismatch between Python and JavaScript's handling of weekday indices, leading to potential bugs in date-related functionalities. Specifically, while JavaScript treats Sunday as 0, Python treats Monday as 0 as you did in your PR. The thing is, one way or another, you have to align both languages somehow, either you use Python's way, or Javascript's way. I chose Javascript's way because it was easier to maintain, thus I added the functions to send the data to the frontend in Javascript's way. Accepting your PR (#174) will add a discrepancy that will particularly affect scripts that depend on synchronized day indices between the client and server sides, leading to calculation errors and display issues. Maintaining alignment with JavaScript conventions in the backend ensures that both sides interpret weekday indices consistently, avoiding these issues. Now, maybe your specific problem is due to something else, if you're still interested, perhaps we can have a look at it together. |
|
Damn, it's okay thanks for checking not sure why it's doing that
…On Sat, May 25, 2024, 4:50 AM Adams Pierre David ***@***.***> wrote:
Hi @nadermx <https://github.com/nadermx>, I've reviewed and tested your
changes. Unfortunately, it introduces a mismatch between Python and
JavaScript's handling of weekday indices, leading to potential bugs in
date-related functionalities.
Specifically, while JavaScript treats Sunday as 0, Python treats Monday as
0 as you did in your PR. The thing is, one way or another, you have to
align both languages somehow, either you use Python's way, or Javascript's
way. I chose Javascript's way because it was easier to maintain, thus I
added the functions to send the data to the frontend in Javascript's way.
Accepting your PR <#m_-5618441542710306507_174> will add a discrepancy
that will particularly affect scripts that depend on synchronized day
indices between the client and server sides, leading to calculation errors
and display issues.
Maintaining alignment with JavaScript conventions in the backend ensures
that both sides interpret weekday indices consistently, avoiding these
issues.
Now, maybe your specific problem is due to something else, if you're still
interested, perhaps we can have a look at it together.
—
Reply to this email directly, view it on GitHub
<#172 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABYACXHI7WXWQFTCGA2RCTLZEBUGDAVCNFSM6AAAAABFS3UJACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZRGIYDSNZTGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Describe the bug
Even in the example page, it shows Sunday-Thursday days avaiable to work.
To Reproduce
Make monday day avaiable to work, shows only tuesday as day avaiable, and says no one avaible to work on tuesday.
Expected behavior
Should show monday
Can you fix the bug?
The text was updated successfully, but these errors were encountered: