Loading...
 
Skip to main content

Category: Consistency

Consistency
Show subcategories objects

Name Type
PluginSplit needs quadrant editing
I should be able to edit each quadrant:
http://tikiwiki.org/SWOT
tracker item
Popups Not Working Right in Trackerlist and Tracker Filter Plugins
The same problem is happening with the default tracker interface, as well as the trackerlist and tracker filter wiki-plugins. Essentially, if you want to display a given tracker field in a popup window when mousing over one of the listed tracker fields (i.e. fields that display as hyperlinks when listing tracker items), then that field MUST already be displayed in the listing. This behavior makes no sense, as it is pointless to display an already displayed field in a popup window.

~~#30C:__You can actually view this problem, by listing your own tikiwiki bug items, and mousing over the bug title.__ A small, but empty, popup window displays.~~

Using Mozilla Firefox browser 3.6.9, and IE 8

Quick tracker definition...

[TRACKER]
trackerId = 1
name = IT Skills
description =
descriptionIsParsed = n
useExplicitNames = n
showStatus = n
defaultStatus = o
showStatusAdminOnly = n
outboundEmail = ed@edmundcscott.com
simpleEmail = n
newItemStatus = o
modItemStatus =
writerCanModify = n
writerGroupCanModify = n
showCreated = n
showLastModif = n
defaultOrderKey = -2
defaultOrderDir = asc
useComments = n
showComments = n
useAttachments = y
showAttachments = n
attachmentsconf = 0,1,3,0,2,0,0,0
useRatings = n
ratingOptions =
categories =

[FIELD1]
name = Skill
position = 10
type = t
options = 0,20,,,50,n
isMain = y
isTblVisible = y
isSearchable = y
isPublic = y
isHidden = n
isMandatory = y
[FIELD2]
name = Last Used
position = 20
type = j
options = d
isMain = n
isTblVisible = y
isSearchable = y
isPublic = y
isHidden = n
isMandatory = y
[FIELD3]
name = Years
position = 30
type = D
options = 0.5,1,2,3,4,5,6,7,8,9,10
isMain = n
isTblVisible = y
isSearchable = y
isPublic = y
isHidden = n
isMandatory = y
[FIELD4]
name = Level
position = 40
type = D
options = Advanced, Basic, Expert, Intermediate
isMain = y
isTblVisible = y
isSearchable = y
isPublic = y
isHidden = n
isMandatory = y
[FIELD5]
name = Company
position = 50
type = D
options = Chrysler / RSB, ITTVIS / RSI, Qwest / US West, University of Kansas, University of Colorado, WTSI
isMain = n
isTblVisible = y
isSearchable = y
isPublic = y
isHidden = n
isMandatory = y
[FIELD6]
name = Position
position = 60
type = D
options = Associate Software Engineer, IT Project Coordinator, Post Doctoral Research Scientist, Programming Consultant, Research Assistant, Research Associate, Software Engineer, Systems Integrator, Team Lead, Web Designer/Developer
isMain = n
isTblVisible = y
isSearchable = y
isPublic = y
isHidden = n
isMandatory = y
[FIELD7]
name = Description
position = 70
type = a
options = 1,60,15,5000,20,1000,n
isMain = n
isTblVisible = y
isSearchable = y
isPublic = y
isHidden = n
isMandatory = y
tracker item
Consistency in syntax usage for List, ListExecute and CustomSearch plugin
On Tiki23 I set a CUSTOMSEARCH plugin to display a list of tracker items in a table output template with some actions buttons for each rows.

{CODE()}
{DIV(type="span" class="click-modal")}[tiki-tracker-update_item?trackerId=22&itemId={display name="object_id"}&modal=1|{icon name="edit" iclass="text-warning mx-2 click-modal"}]{DIV}
{CODE}

It work just fine.

But if I try the same on a List or ListExecute plugin, the "&" in the url are changed to "&" which is breaking the link. You have to add for the column "mode=raw".

Would be nice to have the (same) behaviour like in the CustomSearch plugin (no change)

---


Complete plugin code to reproduce.
{CODE()}
{LISTEXECUTE()}
{filter field="tracker_id" content="22"}
{filter field="tracker_status" content="o OR p"}
{OUTPUT(template="table")}
{column label="Date" translatelabel="y" field="date" mode="raw"}
{column label="Name" field="name" translatelabel="y" mode="raw"}
{column label="Month" field="month" translatelabel="y"}
{column label="" field="action"}
{OUTPUT}
{FORMAT(name="date")}{display name="tracker_field_productsboughtDate" format="date"}{FORMAT}
{FORMAT(name="name")}{display name="tracker_field_productsboughtCustomer" format="objectlink"}{FORMAT}
{FORMAT(name="month")}{display name="tracker_field_productsboughtMonthOrder"}{FORMAT}
{FORMAT(name="action")} {DIV(type="span" class="click-modal small")}[tiki-tracker-update_item?trackerId=22&itemId={display name="object_id"}&modal=1}|{icon name="edit" iclass="text-primary mx-2 click-modal"}]{DIV} {DIV(type="span" class="click-modal small")}[tiki-tracker-insert_item?trackerId=11&modal=1}|{icon name="cash-register" iclass="text-success mx-2 click-modal"}]{DIV}{FORMAT}
{ACTION(name="Close")}
{step action="change_status" from="p" to="c"}
{ACTION}
{LISTEXECUTE}
{CODE}

---

Another example is the fact that most of the time the expected value for "field" if it is to be filled with a tracker field parameter must start with "tracker_field" but not for the plugin ListExecute modify-item parameters. This add confusion to people new to the plugin ListExecute.

{CODE(caption="Not accepted)}
{step action="tracker_item_modify" field="tracker_field_paymentsStage" method="add"}
{CODE}

{CODE(caption="Accepted)}
{step action="tracker_item_modify" field="paymentsStage" method="add"}
{CODE}
tracker item
Preview (with mouse over) in the file galleries is not working correctly?
{syntax type="tiki" editor="plain"}
When you move with the mouse over an item in the file gallery, and it is an image, it displays it beautifully, but when the image is too large (and in practice it is), then the display 'falls from your screen'
tracker item
print to pdf doesn't use the custom css from the L&F control panel
print to pdf doesn't use the custom css from the L&F control panel
tracker item
Wrong user logged in Admin Logs
I am using Tiki v13 connected to LDAP

I logged in with testeinternet (new user from AD), and the Tiki user was successfully created after LDAP import.
I logged in with admin(tiki user)
added testeinternet to LAB group (here is the error the user that was logged for this action was testeinternet and not admin, as you can see in log id 685)

Logs from Action Logs
---
686 login 17:03 admin logged out 127.0.0.1 Mozilla/5.0 (Windows NT...
685 admingroups 17:03 testeinternet added testeinternet to LAB 127.0.0.1 Mozilla/5.0 (Windows NT...
684 admingroups 17:03 admin created group LAB 127.0.0.1 Mozilla/5.0 (Windows NT...
683 login 17:02 admin logged from http://localhost/tiki/tiki-index.php 127.0.0.1 Mozilla/5.0 (Windows NT...
682 login 17:02 testeinternet logged out 127.0.0.1 Mozilla/5.0 (Windows NT...
681 login 17:02 testeinternet logged from http://localhost/tiki/tiki-index.php 127.0.0.1 Mozilla/5.0 (Windows NT...
---
tracker item
Profile soft (UX/UI) revamp proposal
Profile user experience can be improved.

While effort should continue to improve existing profiles, shouldn't it make sense to focus first on easy steps that can be done:

* Is Profiles the right word to name ? (https://en.wikipedia.org/wiki/Profile), it means so many things...
May be there is not a single word for this. May be we should use word that doesn’t mean anything (Tikifigurator :-) ) so no confusion.
* tiki-admin.php?page=profiles should be revamped
++ {img type="src" src="http://avan.tech/dl2287?display" thumb="box"}
** Help text could be added to explain what, how, why... (may be reuse the remark box - I can’t find it useful for new user - links didn’t work for me in trunk local)
** We could display only one version of the profile, the one that work with the running Tiki (and remove anything about 3x, 4x, 5x, etc)
++ {img type="src" src="http://avan.tech/dl2288?display" thumb="box"}
** We could display already a list of profile by default (last 10 updated) (not the mini profile); it will help to understand what this does
** Remove or modify the "Profile type" selector (confusing)
** The profile repository dropdown could be moved under the advanced tab (till there are more repository)
* When applying a profile
** Once a profile is selected and ready to be applied we shouldn’t see (again) other profiles but only the one selected (so we have more room to see the profile content: setting, instructions, etc)
++ {img type="src" src="http://avan.tech/dl2289?display" thumb="box"}
** The table where is displayed the profile information should be adapted to the size of it’s content (scroll, content is hidden)
** Add some screen shot (corresponding to the version of the Tiki running)
* After a profile is applied
** Hide the long list of "changes has been applied" (viewable on click) - (if someone want to see it he can but we don’t need to put that long and scary list)
** A Success message should be seen first ;)
** The result should be mordernized and help doc should guide better. This screen show the result and it is not the nicest design we can expect with Tiki today and user doesn’t have any guidance about what to do from here.
++ {img type="src" src="http://avan.tech/dl2290?display" thumb="box"}
tracker item
provide some button in Plugin Convene for users to save their choices (or cancel) other than the edit button they clicked on to display the options to choose from to make it more consistent with the rest of tiki
provide some button for users to save their choices (or cancel) other than the edit button they clicked on to display the options to choose from to make it more consistent with the rest of tiki

See it reproduced here:
https://tiki.org/Roundtable+Meeting+2016+09
tracker item
Quotes in search doesn't do what the documentation says
{flash type="url" movie="display647" width="1208" height="434"}
tracker item
Re: gets added to Forum Topic title, after a posting has NOT been submitted
When adding a post to the forum and do not select a smiley (which defaults to a required field - which I dont think is correct). This causes your post to rejected and redisplayed, with a red prompt by the smily field. The Title has Re: preappended when it should not. It is easy to miss when making the corection and re-submitting.
tracker item
realName user preference is not used in trackerlist, tracker, and pretty tracker
Community / User features /
User Preferences Screen: yes

Community / General /
Show user's real name instead of login (when possible): yes

The realName user preference is not used in trackerlist, tracker, and pretty tracker. Actually, why the when possible? Is not it where implemented?

Note that
- in my case the e-mail is used as the login name
- it does work when adding new comments to trackers
used: TW5.0Beta1
tracker item
Refresh by clicking page title does not work with parameters
{syntax type="tiki" editor="plain"}
All wiki pages have the option to refresh them by clicking on their title. For a page e.g. ...&itemId=5, it does not work.

TW5.0Beta1
tracker item
Registering to a site : message sent to user - errors in mail structure and content
Hello,

I am testing the registrations into one of the sites I develop (the first test 4.1)
The message sent to the user as various content and "structure" errors.

1- the system inserts HTML comment [<!-- TPL: mail/user_validation_mail.tpl -->]
because the option
(preference name: log_tpl) was activated
These comment are displayed into the message and placed (3 times) in not a right place.
A blank line into the mime definition is interpreted as begin of text.

2- Even the option is not used there is a blank line into mime commands so the second part of mime definition are not taken in account and appear as document text....

Join three file *.eml
*name ended "b-html_v4b.eml" which is sent with option log_tpl
*name ended "-b.eml" without option log_tpl
*name ended "-b-v5.eml" without option log_tpl with corrections integrated : mail well displayed has text:plain

This makes us unable to start normal exploitation of the site, till is not solved.
We track all messages display and check French translation.

I don't had time till know to go to the soft structure to find the error.

Best regards

It should be useful for registered developers to have the option to join documents to the bug-track during main redact

''__the b-html_v4b.eml__''
X-Account-Key: account36
X-UIDL: 12627.....48.mail97.ha.ovh.net,S=1947
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <teawik@trebly.net>
Delivered-To: bty-........@trebly.net
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
by b0.ovh.net with SMTP; 6 Jan 2010 01:33:36 -0000
Received: from localhost (HELO mail97.ha.ovh.net) (127.0.0.1)
by localhost with SMTP; 6 Jan 2010 01:33:36 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
by b0.ovh.net with SMTP; 6 Jan 2010 01:33:36 -0000
Delivered-To: trebly.net-bty-...........@trebly.net
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
by b0.ovh.net with SMTP; 6 Jan 2010 01:33:36 -0000
Received: from localhost (HELO mail97.ha.ovh.net) (127.0.0.1)
by localhost with SMTP; 6 Jan 2010 01:33:36 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
by b0.ovh.net with SMTP; 6 Jan 2010 01:33:36 -0000
Received: from unknown (HELO teawik.trebly.net) (bty@trebly.net@213.251.189.205)
by ns0.ovh.net with SMTP; 6 Jan 2010 01:33:35 -0000
MIME-Version: 1.0
From: Teawik@trebly.net
Return-Path: Teawik@trebly.net
Reply-To: Teawik@trebly.net
Subject: <!-- TPL: mail/user_validation_mail_subject.tpl -->Votre inscription Tiki (teawik.trebly.net)
X-Ovh-Tracer-Id: 16748887014789590094
X-Antivirus: avast! (VPS 100105-0, 05/01/2010), Inbound message
X-Antivirus-Status: Clean

<!-- /TPL: mail/user_validation_mail_subject.tpl -->
Content-Type:text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <kvsxny......@teawik.trebly.net>
To: bty-...........@trebly.net
X-Ovh-Tracer-Id: 16748605539809995854
X-Ovh-Remote: 213.251.189.205 ()
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N

<!-- TPL: mail/user_validation_mail.tpl -->Bonjour BTY044,
Vous (ou quelqu'un d'autre) a inscrit cette adresse électronique à teawik.trebly.net
Si vous voulez pouvoir vous connecter sur ce site, vous devrez suivre le lien suivant pour la première connexion :
http://teawik.trebly.net/tiki-login_validate.php?user=B?????&pass=........................
Bonne visite sur le site!

<!-- /TPL: mail/user_validation_mail.tpl -->


''__the -b.eml file__''
X-Account-Key: account36
X-UIDL: 1262928532.31100.mail97.ha.ovh.net,S=1715
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <teawik@trebly.net>
Delivered-To: bty-a.......ly.net
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
by b0.ovh.net with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from localhost (HELO mail97.ha.ovh.net) (127.0.0.1)
by localhost with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
by b0.ovh.net with SMTP; 8 Jan 2010 05:28:51 -0000
Delivered-To: trebly.net-bty-...........@trebly.net
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
by b0.ovh.net with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from localhost (HELO mail97.ha.ovh.net) (127.0.0.1)
by localhost with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
by b0.ovh.net with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from unknown (HELO teawik.trebly.net) (bty@trebly.net@213.251.189.205)
by ns0.ovh.net with SMTP; 8 Jan 2010 05:28:50 -0000
MIME-Version: 1.0
From: Teawik@trebly.net
Return-Path: Teawik@trebly.net
Reply-To: Teawik@trebly.net
Subject: Votre inscription Tiki (teawik.trebly.net)

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <kvwxw7.......trebly.net>
To: bty-........@trebly.net
X-Ovh-Tracer-Id: 14020268591991991374
X-Ovh-Remote: 213.251.189.205 ()
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
X-Antivirus: avast! (VPS 100107-1, 07/01/2010), Inbound message
X-Antivirus-Status: Clean

Bonjour BTY05,
Vous (ou quelqu'un d'autre) a inscrit cette adresse électronique à teawik.trebly.net
Si vous voulez pouvoir vous connecter sur ce site, vous devrez suivre le lien suivant pour la première connexion :
http://teawik.trebly.net/tiki-login_validate.php?user=BTY05&pass=0de72c4e5ca890a3b931d7dfab38f992
Bonne visite sur le site!

''__the "b-v5.eml" (manually corrected on output)__''

X-Account-Key: account36
X-UIDL: 1262928532.31100.mail97.ha.ovh.net,S=1715
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <teawik@trebly.net>
Delivered-To: bty-a.......ly.net
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
by b0.ovh.net with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from localhost (HELO mail97.ha.ovh.net) (127.0.0.1)
by localhost with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
by b0.ovh.net with SMTP; 8 Jan 2010 05:28:51 -0000
Delivered-To: trebly.net-bty-...........@trebly.net
Received: from b0.ovh.net (HELO queue) (213.186.33.50)
by b0.ovh.net with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from localhost (HELO mail97.ha.ovh.net) (127.0.0.1)
by localhost with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
by b0.ovh.net with SMTP; 8 Jan 2010 05:28:51 -0000
Received: from unknown (HELO teawik.trebly.net) (bty@trebly.net@213.251.189.205)
by ns0.ovh.net with SMTP; 8 Jan 2010 05:28:50 -0000
MIME-Version: 1.0
From: Teawik@trebly.net
Return-Path: Teawik@trebly.net
Reply-To: Teawik@trebly.net
Subject: Votre inscription Tiki (teawik.trebly.net)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <kvwxw7.......trebly.net>
To: bty-........@trebly.net
X-Ovh-Tracer-Id: 14020268591991991374
X-Ovh-Remote: 213.251.189.205 ()
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
X-Antivirus: avast! (VPS 100107-1, 07/01/2010), Inbound message
X-Antivirus-Status: Clean

Bonjour BTY..,
Vous (ou quelqu'un d'autre) a inscrit cette adresse électronique à teawik.trebly.net
Si vous voulez pouvoir vous connecter sur ce site, vous devrez suivre le lien suivant pour la première connexion :
http://teawik.trebly.net/tiki-login_validate.php?user=BTY..&pass=..........................
Bonne visite sur le site!



END!



tracker item
A new page in a wiki structure doesn't inherit categ perms from structure parent but only object perms (unexpected for intranet type of sections of wiki structures)
Quick sensation in a production site of mine:

A new page in a wiki structure doesn't inherit categ perms from structure parent but only object perms (unexpected for intranet type of sections of wiki structures)

It does inherit permissions from the parent when local permissions are applied to the parent wiki page. However, in my opinion, category permissions (when there are no object permissions but category permissions) should be either applied by default to the new child page from the parent in the structure, or at least offer/warn the user about it with a checkbox for the user to select to copy categ. permissions also.
tracker item
Remove breadcrumbs from 1.10
This feature has never worked well. There is no active development on it. Should be moved to mods or just removed.

But there is not unanimity on this yet :-)
http://dev.tikiwiki.org/Endangered+features
tracker item
Remove requirement of global tiki_p_view wiki pages in order to allow to manage one local structure
To be reproduced, see:
http://xavi-9794-5464.show.tikiwiki.org/tiki-index.php?page=D1+Cover
u: admin
p: 12345

And see the same page as user:
u: user1
p: user1
which has been granted local permission to view and edit that page, and global permission to edit structures. If you attempt to go to edit the structure,
http://xavi-9794-5464.show.tikiwiki.org/tiki-edit_structure.php?page=D1+Cover&page_ref_id=1

you get:
{QUOTE()}
Error: You do not have permission to use this feature: tiki_p_view
{QUOTE}

Potential Workaround:
Comment out the check for the permission to display any part of the edit strcutures interface. Line 22 from tiki-edit_structure.php should become:
{CODE()}
//$access->check_permission('tiki_p_view');
{CODE}

And line 123 from templates/tiki-edit_structure.tpl should change from:
{CODE()}
{if $editable == 'y'}
{CODE}
to
{CODE()}
{if $editable == 'y' && $tiki_p_edit == 'y'}
{CODE}

Should that be enough?

I couldn't test properly due to the interference of this other bug which prevents assigning object permissions:
https://dev.tiki.org/item5916
tracker item
Removing a tracker field should remove also the references to that field in the popup fields definition in the tracker properties
Removing a tracker field should remove also the references to that field in the popup fields definition in the tracker properties
tracker item
renaming perspectives in a category doesn't work
Using workspaces, when changing workspace names after creation, editing the category to rename its elements works OK for wiki pages and file galleries, but perspectives' names are not changed.
Seems "profile_symbols" & "objects" tables are not updated.
tracker item
respect/obey object permissions (beyond global) with plugin pivottable
respect/obey object permissions (beyond global) with plugin pivottable
To be reproduced in short.
Cases to be handled properly:
a) granted globally but restricted locally
b) granted only locally

Reproduced:
admin access:
http://xavi-9794-6148.show.tikiwiki.org
u: admin
p: 12345

__Case a) granted globally but restricted locally__
http://xavi-9794-6148.show.tikiwiki.org/tiki-index.php?page=Homepage+for+Staff
u: client1
p: client1
Group clients has global perms to view and edit wiki pages, but for that specific page, Clients can only see the page, and not edit it (managed through object perms).
However, user client1 currently can see the button to "Edit pivot table" (by mistake), while can't see the button to edit the wiki page (as expected). If the user clicks at edit pivot table, can change controls, but at saving time, nothing is changed (as expected, since he/she doesn't have perm on that page to edit it).

__Case b) granted only locally__
http://xavi-9794-6148.show.tikiwiki.org/tiki-index.php?page=Homepage+for+Staff
u: staff1
p: staff1
That page has object perms (not global) for group staff to view and edit. User staff1 can edit the page, but this user doesn't see the controls to edit the pivottable plugin.
tracker item
RSS feed order is inversed for tiki-tracker_rss.php
For example:
http://dev.tikiwiki.org/tiki-tracker_rss.php?trackerId=5
tracker item
S5 Slideshow: Videos should float like images
See show instance
tracker item
Save CSS after editing leaves the css file empty on the filesystem
After saving the "Edit CSS" changes, the *.css file is empty!!
tracker item
saving Calendar event in Tracker field type 'Calendar event' scraps changes of other Tracker fields
__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.
tracker item
Scheduler Admin UI untranslateable text
The admin UI for the schedular contains some help text that is strangely totally untranslateable.

/templates/tiki-admin_schedulers.tpl contains this at line 147:
{CODE(Colors="Tiki")}
{remarksbox type="note" title="{tr}Information{/tr}"}
{tr}Use CRON format to enter the values in "Run Time":
<br>
Minute, Hour, Day of Month, Month, Day of Week
<br>
Eg. every 5 minutes: */5 * * * *{/tr}
{/remarksbox}
{CODE}

Since the text is correctly enclosed in tr in curly braces. I am at a loss why this is the case, and why it throws no error?

Also, I seem unable to translate the task descriptions. These are ConsoleCommand, ShellCommand, HTTPGetCommand. I cannot even find the location where they are set. While I figure that admins who want to use schedulers might understand those terms, so task descriptors are slightly less important, but the help text about CRON syntax isn't.
tracker item
Scope for object singleton TikiDb::get() access to Pdo function : incompatibility with php 5.3.2 (on windows)
{syntax type="tiki" editor="plain"}
Hello,

!A problem completely identified
This is a new formulation of 3029 and 3057 problem after near 200 hours of test and debug.

!The problem is now precise and (I hope so) near solution (but depends of quality team (this part has been rewrite for 5.0):

__The solution that I propose establish the compatibility of 4.2 with php 5.3.2.__

!!Not alone may be
!!!Can't end test of changes to submit (just tiki-db-dbo.php)

I can't affirm that I wrote a complete debug version because the execution stop on another problem (track [http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=3115], so it is not ended. I can't be sure that everything is OK.

!!!Note about time spent to be able to participate efficiently to the team

The time spend is not only on TikiWiki, a had to solved installation problems and find a bug into easyphp and addresses resolution on the server.

The problem began with 4.1 and php 5.3.0 and I upgrade to 4.2 and 5.3.2 to be sure of the problem and the available solution.

!Span of the problem :
# Definition of main classes TikiDb and TikiDb_Pdo and PDO->function execution
# Progs : tiki-db-pdo.php, tikisession-pdo.php and naturally pdo.php, tikiDb.php
# PDO extension and behavior of objects and classes

!Description of the nature of the problem and is generation

note : Because I found the nature of the problem, I don't start from the nature of the crash but the analysis, but I produce a selected track made with xdebug var_dump)

# In tiki-db-pdo.php:40 we create the Pdo object
<$dbTiki = new PDO("$db_tiki:$db_hoststring;dbname=$dbs_tiki", $user_tiki, $pass_tiki); >

# just later In tiki-db-pdo.php:49 we set the singleton of TikiDb_Pdo into TikiDb abstract class with scope operator
<TikiDb::set( new TikiDb_Pdo( $dbTiki ) ); >

# further we call In tikisession-pdo.php:28 we can find the session read
< $sth = TikiDb::get()->prepare($qry); >
This instruction generates the fatal error :
__ Fatal error: Call to undefined method TikiDb_Pdo::prepare() in D:\Trebly\Teawik-ld8-422a\lib\tikisession-pdo.php on line 28__

!Explanation and solution implemented
The reason is simple and explained by the error comment :
we try to run the prepare function which is a PDO function on a TikiDb_Pdo object which has no reason to inherit of these Pdo function even <TikiDb::get()->db->prepare> could have a meaning.

Then the solution is in what is made in ZEND lib (not yet used in 4.2), create an interface to PDO into Class TikiDb_Pdo.
This functions and it is written.

! A major question
One important question is why and how the same instructions seems to be available and functions well on Linux (I have a site which runs normally with 4.1, not yet upgraded to 4.2, a to-do)

I believe that the actual solution that I have developed for 4.2 on Windows with PDO (compiled) extension, should be extended to the normal version.

As I have said before I can't confirm completely that the solution is correctly tested and free of bug because, the program have a FATAL ERROR PDOException: SQLSTATE[HY093] later on the prefs restoration I create another report for this.

!!!Complements of information (working around finding and solving bugs):
Note 1 (complement, I will made another little track for this) :
the execute statement written execute() without parameter generates each time a warning message when xdebug is used and php error management activated with STRICT option (default in 5.3.2). This makes necessarily the code lightly slower.

Note 2 :
I developed for other debug for this an enhanced error template according to the error handler which displays much more informations about the context and, into these, the parameter (title) of execute statement. This make an enhancement to find much more quickly the errors.
I will implement a test so that it should be displayed only for administrator.
tracker item
Show PHP error messages