Our pure JavaScript Scheduler component


Post by SIM-LTD »

When RecurringEvents feature is disabled, recurring UI is still visible in EventEditor

To reproduce please open your Basic demo in Scheduler.
Double click a task, see "Repeat" field.
RecurringEvents feature is disabled by default so we do not expect to see the field.
Attachments
Capture d’écran 2019-11-07 à 12.12.53.png
Capture d’écran 2019-11-07 à 12.12.53.png (283.23 KiB) Viewed 787 times
Capture d’écran 2019-11-07 à 12.18.04.png
Capture d’écran 2019-11-07 à 12.18.04.png (161.88 KiB) Viewed 787 times
Capture d’écran 2019-11-07 à 12.13.11.png
Capture d’écran 2019-11-07 à 12.13.11.png (280.34 KiB) Viewed 787 times
Last edited by SIM-LTD on Thu Nov 07, 2019 8:28 pm, edited 1 time in total.

Post by pmiklashevich »

Hello,

The first one is a bug: https://app.assembla.com/spaces/bryntum/tickets/9456-event-editor-recurring-ui-should-be-hidden-when-recurringevents-feature-is-dis/details
We have 3 points (Sorry this could not be in a different post)
It could and should be easily split into at least 2 separate posts. In the first block you reported a bug (accepted). But in the second block you asked questions about the feature behaviour. Please move this part from this post to another thread.

Can I ask you please to review your approach of posting reports/questions here? It would be nice if you could think of forum threads as of javascript functions. They have to follow KISS pattern. Please try to refrain from long introductions and keep only short and simple information about the issue. Just for example, how I would report the first issue:
Title: When RecurringEvents feature is disabled, recurring UI is still visible in EventEditor
Description: To reproduce please open your Basic demo in Scheduler. Double click a task, see "Repeat" field. RecurringEvents feature is disabled by default so we do not expect to see the field.
That's it. Optionally you can upload a screenshot to show URL and Repeat field as a proof. But for this issue it's not needed.

Also each post should follow Single Responsibility pattern. Each thread should contain only one question. I asked you to split posts not just because I want to. But because they cover different areas. For example in this post you mixed up bug report and behavior clarification questions. I can check your bug report very fast but I cannot reply to your questions right away. I would ask the author of the recurring feature to give you the answer, but he is not available right away. First option is to do not reply at all unless I have answers for both parts or he is available. But in this case the bug will "live" longer and the forum post will look ignored. If I reply only to the first question and just ignore the second part, the forum will mark question as replied and it can be forgotten. Then when you ask about "update" we will see the reminder and back to this question again. And the reply time is growing. So to decrease the complexity of the support and make it faster, please try to provide short and clear description and keep to one issue per post.

Sorry, I don't want to offend you just want to save your time and increase support quality for you.

Thanks,
Pavel

Pavlo Miklashevych
Sr. Frontend Developer


Post Reply