Category: Calendar

__Releated to:__ item8186-to-be-synched-fetched-event-details-of-of-Calendar-event-and-details-in-a-Tracker-item-with-Tracker-field-Calendar-item

__The cause:__

Given a Tracker has a field of type 'calendar item' and a number of other fields, for example a 'Textarea' or a 'Textfield'...

Given a user creates a Tracker item and desides to add an event to the Tracker item, __then__ the user can edit the Calendar event from inside the tracker, after the Tracker item is saved the first time (with existing event).

It is quite probable that a user who wants to edit a Calendar event might need to edit another field of the same tracker item at the same time.

Looking at the UI of the Tracker form, a user would most likely asume, that he can add or edit data in the Textarea, then edit and save the event and then save the Tracker item without losing any data.

In fact, when the user clicks at the edit-event button and then the save-event button, __all changes made to the Tracker item in the other fields will be lost.

__Observation:__

After saving the event, the whole page (browser tab) reloads the non-edit version of the page, instead of only saving the Calendar details to the Calendar and keeping the other field's data 'alive'.
Thus if you have filled a form or edited fields previously filled and then edit the event and then save the event, the just filled data get's completely lost

I imagine, that there would be some kind of AJAX event needed that pushed the Calendar event data to the database, without reloading the page.

Depending on the respective Tracker form, this could cause the loss of work and thus frustrate users to some unreasonable extent.

{THUMB(id=45, url="tiki-browse_image.php?imageId=45")}{THUMB}

#Users would highlight the blocks of time they can be around for
#Their name and a color is automatically added to the block they selected
#Times that we want people around for (like shifts) are given a different background
#You can't overwrite someone else's selection
#You can go back and forth to any day in the future (past should be archived)
#Sign in so users don't have to type their name.%%%ideally allows for permissions, only x users can use the room monitor column
#Can also output it as a text list, username with their hours after it etc

Related:
*((Project Management))
*[tiki-view_tracker_item.php?itemId=1604|Timesheet with time tracking (stopwatch)]



Feature request prepare by Lucy (Support.Mozilla.com)

Bottom banner bar appears on calendar although not checked at the general layout options level.

Plus calendar is not part of sections proposed in admin layout per section.

{syntax type="tiki" editor="plain"}
The link to the RtM calendar event on tiki.org currently should be the SEFURL version, e.g. https://tiki.org/tiki-calendar-view_item?calitemId=337 (or maybe something even shorter?) and not https://tiki.org/tiki-ajax_services.php?controller=calendar&action=view_item&calitemId=337

Also, it should be easier to share it, imho.

I am having problems using the flash plugin in TW3, that a TW2.4 site test that I have does not have.

1 - First of all the flash module code has to be re-written for it to work at all.
from:
{CODE()}{FLASH(movie="http://www.youtube.com/watch?v=JeqdtbYz_M4")}{FLASH}{CODE}
to:
{CODE()}{FLASH(movie="http://www.youtube.com/watch/v/JeqdtbYz_M4")}{FLASH}{CODE}
Can the edit window button be modified to insert the correct code?

2 - 'Flash player not available' appears in slides of wiki pages although wiki pages themselves work fine.

3 - In calendar, list view shows flash movie but the preview doesnt - gives the error message 'Flash player not available'. Any tips or directions to solve these problems??

new or modified calendar items...

I discovered an issue with my calendars a couple of weeks ago. It turns out that it was caused by one of our users giving a certain input to a new calendar item. Essentially, they were attempting to add an image to a calendar event and submitted an improperly formatted string in the description field. Instead of using the the 'Image' button on the new calendar item page (tiki-calendar_edit_item.php) to load their image, they did some sort of copy/paste of the image or its syntax from a page using the ''wiki'' syntax.

Their input in the database looked like:
<p>~np~{img fileId="791"}~/np~</p>
But the correct syntax looks like:
<p><img alt="" src="display791" /></p>

After hunting this bug down, it was determined that it was in fact the cause of our calendars getting hung during the loading screen, and this resulted in the WSOD. After simply deleting the two entries from our database that had the incorrect syntax, the entire issue was resolved, and the calendars began loading correctly again.

In pursuit of a fix for this kind of bug happening again, maybe there is some way to prevent a write to the database when the title or description field (in tiki-calendar_edit_item.php) contains this form of syntax?

Hopefully, there will be a way to restrict this from happening, as it took a couple of weeks to hunt this bug down, since we had no idea when or where it originated from.

I'm submitting this bug report in case future users experience this same type of issue.

The following have been lost for the calendar module:
* "Checkerboard" pattern of changing the background on alternating days
* Font size of the day numbers
* Header styling
* Highlighting of today (today always has a class of calhighlight)

Also the highlighting of today has been lost for the full calendar as well (in all views - monthly, weekly, etc.)

Please see:
http://sourceforge.net/mailarchive/forum.php?thread_id=10026369&forum_id=12569

In tiki-browse_gallery.php, there is Sort Images by [ Name | Date | Hits | User | Size ] so robots can think these are all different pages

Several SQL queries only work with mysql because it is not SQL92 compliant. Some bugs are already fixed now but at least the case sensitivity bug is still there.
If you create a table with columns and later use a query you have to use the exact name and not a name with different cases, an example is:
Warning: postgres7 error: ERROR: column i.categoryID does not exist in query:
select i."calitemId" as "calitemId", i."name" as "name", i."description" as "description", i."start" as "start", i."end" as "end", i."url" as "url", i."status" as "status", i."priority" as "priority", c."name" as "calname", i."calendarId" as "calendarId", i."locationId" as "locationID", i."categoryID" as "categoryID", i."nlId" as "nlId" from "tiki_calendar_items" as i left join "tiki_calendars" as c on i."calendarId"=c."calendarId" where ((i."calendarId"=?) and ((i."start" > ? and i."end" < ?) or (i."start" < ? and i."end" > ?)) and ((c."personal"='y' and i."user"=?) or c."personal" != 'y')) order by "start" asc
in /usr/share/tikiwiki/lib/tikidblib.php on line 134

this is because the column is named categoryId and not categoryID.
I think in this example i manually fixed on my side another Id that is locationId where the query used locationID which is not existent.

This not only occurs in the calender section but this is just the sections that i remember where the error occurs.

Yet another bug with the strange layout of the calendar feature. I created one event, that spans several days, each of them for the whole of that day. On all days this event is painted at the top of day, in the view that you get when you click on the event in module (that I placed left). All of them.

Except for the very first. Seemingly because of no reason at all it appears vertically centered... See attachment.

Thanks
hman

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

Using latest 1.9.cvs (from 13th june 2007), and simple.css and tpl's.

Maybe related to these other bug reports by me a momoent ago with Calendars:
[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1136&show=view&offset=0&reloff=2&status=op&trackerId=5&sort_mode=created_desc|bug 1]
[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1138&show=view&offset=0&reloff=0&status=op&trackerId=5&sort_mode=created_desc|bug 2]

I attempted to create a simple event at this newly created calendar ("Comisión Web", see previous bug reports). I get a red message saying ~~red:Syntax error~~ (in Spanish, due to lang interface in Spanish).

See screenshot attached (if I can), after posting this bug report.
That's the text I introduced:
{CODE()}
Prueba de item: retocar estilo de tema de la web (a partir de simple.css)
{CODE}
-----
Update: when using tikineat.css and tpl's, or smartiki.css and tpl's, for instance, everything works fine, as expected.

{syntax type="tiki" editor="plain"}
Admin->Modules->
Assign New Module, select calendar from dropdown:

Preview-> works ok, shows calendar
Assign-> returns System error page:

System error

The following error message was returned:

Column 'params' cannot be null

The query was:
insert into `tiki_modules`(`name`,`title`,`position`,`ord`,`cache_time`,`rows`,`groups`,`params`,`type`) values(?,?,?,?,?,?,?,?,?)

Values:

1. calendar_new
2.
3. l
4. 1
5. 0
6. 10
7. a:1:{i:0;s:10:"Registered";}
8.
9.

The built query was likely:
insert into `tiki_modules`(`name`,`title`,`position`,`ord`,`cache_time`,`rows`,`groups`,`params`,`type`) values('calendar_new','','l','1','0','10','a:1:{i:0;s:10:\"Registered\";}',NULL,NULL)

t.o calendar: warn the user about the time zone being used at time selection by the user

I added an event at a calendar in Tiki.org community site, and selected the chosen time for the event (13h UTC).
https://tiki.org/tiki-calendar_edit_item.php?viewcalitemId=142

There was no indication of which time zone was Tiki going to understand for my selection, so I chose the time in my time zone: 15h (UTC+2). Tiki stored that time as if it was at 15h UTC, and then display the time of the saved event to me as 17h (UTC+2).

So Tiki was expecting the user to introduce the time in UTC, apparently, but there was no indication about that to the user. Some info should be shown. Maybe that will depend on the settings being set in the tiki site (there are a few combinations to test, I guess). So at least I'll leave the bug report here about it.

I recall Jonny saying that there was some new jquery library that was aware of time zones for time and date pickers? :-)
---
In addition, the time recorded for the item doesn't match the time the user selected in the edit form, or even shown when the user opens the item for edition again. This type of issue seems to have been solved recently (months) in tracker fields date and time (date picker, by developer kroky6), so it may probably just need porting similar fix to the calendar feature itself {sign user="xavi" datetime="2017-01-12T14:51:14+00:00"}

https://tiki.org/calendar has gone mad, and self-refreshes indefinitely.

I wanted to reproduce a bug in the calendar using our own calendar there, but I could'nt and noticed this issue.

Coming from custom rewrite rules? Bug in recent 15.x code?

At https://tiki.org/calendar, logged as registered user, the "today button is disabled and can't be used to set the date picker just above.

When a user click on "today" is expected things to be set on today. (the since last visit module is dependant of the date picker date).
Everything should be turned into "today" and not using different dates for different component.

{syntax type="tiki" editor="plain"}
The title of the module "upcoming_events" is displayed anyway without taking care of the groups defined and existence of calendars with rights.

This title disturbs users who not have the access. How to say, sorry this title should not be displayed don't take care, this as no mean but I can't change nothing, then you are ridiculous and must consider that this module is not usable.

A weird bug which was showing in tiki 4.x (calendar), and nowadays, I've seen something similar using 5.x alpha at dev.tw.o:

The user is redirected to a blank page with just an email address shown, even if the user didn't click anywhere.

To reproduce:
http://dev.tikiwiki.org/tiki-view_tracker.php?trackerId=5&status=o&sort_mode=f_41_desc&filterfield=54&&filtervalue[54]=xavi&&&&filtervalue[56]=Accepted&&offset=30

Pass the mouse over the item saying "2 errors editing articles in tiki 3.3 ".
With no click (just passing the mouse over, using Firefox 3.6.2), you are shown a blank page with just "email@domain.org" on top.

That item corresponds to:
http://dev.tikiwiki.org/bug2893


This is something which is also happening to a calendar in a tiki 4.x site, when the event body has some email address, it seems.

HTH

Hey everyone,

The calendar backdrop likes to not go away when escaping out of the calendar. This prevents a user from doing anything on the webpage without refreshing.

This is the element in question : <div class="modal-backdrop fade in"></div>

How to recreate the bug:
1. Double click on a day on the calendar, it has to be a double click
2. Click on any of the text fields
3. Hit escape
4. The backdrop should stay and refuse to go away without a refresh

The odd thing about this bug is that you have to double click on a calendar day to create it. Single clicking the day allows the escape key to work as intended. I was able to recreate the bug on the demo site.

{syntax type="tiki" editor="plain"}
Hello Devs,

I did upgrade a site to 7.1 this weekend.

Using WYSIWYG/CKE I have the following prblem:

In some features of the Tiki 7.1 the output the editor is just the plain
HTML Source.

That means, not in Wikipages, but in the articles and in the calendar
events, there is not a nice text with formatting bold, italic, colors
and pictures etc, but only the plain HTML source code visible to the
website user/visitor.

The WYSIWYG/CKE editor works normal and I can see the content just
normal like ever, being in the editing mode. But when I save, I can just
see the source code, like it would be in codeplugin.

This affects as said articles and calendar (perhabs more, I will hope to
find out) but it does not affect wikipages by now.

And it affects existing articles and events aswell as newly edited.

(worked well in 6.x before)

Thx for reply and wish a nice sunday to all,
cheers
Torsten

The ((tw:Roundtable Meetings|Tiki Roundtable Meetings)) are to be held __monthly every 3rd Thursday at 14h UTC__. Please make it possible to be able to do this in Tiki.

This should work with recurring events. So people in different time zones will see the event in their time, depending on daylight saving time (DST)

When editing a calendar event, some characters in the event title displays as HTML code, in the modal title. For example, John's "Birthday" displays as ~np~John&#309;s &quot;Birthday&quot; ~/np~.

The file is tiki-calendar_edit_item.tpl, I believe.

Also, the wrench/spanner icon at the right side of the modal title doesn't seem to do anything. Is it meant to be just an icon to indicate the edit screen is displaying? If so, it's misleading since other instances of this icon are clickable to produce a popup list of links, etc. IMO it should be removed if it is just an icon. Or if it is meant to be clickable, it doesn't seem to be working.

{syntax type="tiki" editor="plain"}
Tiki calendar object permissions do not work properly. (Or, I am not understanding how they should work correctly.)

It is my understanding that object permissions should override global permissions. In the case of calendar, this means that if there are no global permissions granted, but there are object permissions set on a calendar, the calendar should comply with the object permissions. This is not how calendar currently works.

In order for a user to add an item to a calendar, they must have the add item permission in global permissions, regardless of whether the object permissions grant them that permission.

In the snapshot below, I have it set up as follows to demonstrate this.

User: admin
PW: 12345

User: reg
PW: 12345
Member: Registered

Registered is granted no calendar related permissions globally.

I created a calendar "test" and granted Registered add, change, browse, and view calendar permissions in the object permissions.

User "reg" is unable to add items (button does not appear) to calendar "test" from -+tiki-calendar.php?calIds=1+-

I believe that "reg" should be able to add items, as the object permissions allow them to, regardless of global permissions. Note that the view permission seems to be working correctly on the object level of permissions for calendar, as "reg" is still able to view the calendar, though that permission is not granted globally.

Let me know if I'm just crazy and over-thought this into a dumb :)

Tiki tabs are a nifty feature to make a page cleaner / simpler.

For example for trackers, we have:

View / Comments / Attachments/ Edit

However, I want to be able to link directly to "edit" so someone could be invited to edit their user tracker or add a bug or add a calendar item.

I would like something like this:
tiki-view_tracker_item.php?trackerId=5&itemId=978#view
tiki-view_tracker_item.php?trackerId=5&itemId=978#edit


There seems to be the start of something:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=980&show=edit