Category: Community projects

convene plugin: prevent the user to add default info (Add or Add user string) instead of the real username or a different string

See it reproduced here:
https://tiki.org/Roundtable+Meeting+2016+09

Create a bash or php script which will convert the old type Tracker rating field to the new one for upgraders (people who upgrade) using this field.
---
We would benefit in the Tiki Community itself since we would re-use all the information added by users over the years to indicate which bugs in the bug tracker are more important to them. It could be a way to review the list of pending bugs by priority according to user's opinion expressed in that rating option. Thanks luci for filling this wish report {sign user="xavi" datetime="2014-09-21T07:04:05+00:00"}

Create a profile for an improved Issue Tracker (with linked trackers) using the latest improvements in 14x

See this discussion:
[http://irc.tiki.org/irclogger_log/tikiwiki?date=2015-03-17,Tue&sel=180#l176]

We (geoff and xavi) were considering the benefits of creating a Profile out of a use case of trackers, plugin list and custom search. To achieve such a goal, a pre-liminary step is to implement a tiki site in a show.t.o instance here in dev.t.o, which is similar to a custom setup that Geoff has for some project. And then, convert that setup into a profile in profiles.t.o

More to come. And feel free to join us if you have some ideas or spare time to contribute to this project! :-)
(you will learn how to create a profile out of a tiki site)

show instance (based on Tiki12 LTS):
http://xavi-9794-5603.show.tikiwiki.org/
u: admin
p: 12345

Creation of tracker items with __relative dates__ from profiles shows the right date in view item but empty when editing item

By __relative dates__ I mean something like:
{CODE()}
+1 day 2 hours
{CODE}

(See more: http://www.php.net/manual/en/function.strtotime.php )

See it reproduced in the show instance of this other bug report ([item5254]):

http://xavi-9794-5254.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=4
u: admin
p: 12345

This item was created through applying the profile "Tracker_as_Calendar_12"

Defined as:
{CODE(ln="1")}
type: tracker_item
ref: event_004
data:
tracker: $Tracker_as_Calendar_12:trac_as_cal
status: open
values:
- [ $Tracker_as_Calendar_12:trac_as_cal_summary, A big conference ]
- [ $Tracker_as_Calendar_12:trac_as_cal_location, room 2.3 (15 seats) ]
- [ $Tracker_as_Calendar_12:trac_as_cal_start_date, +1 day ]
- [ $Tracker_as_Calendar_12:trac_as_cal_end_date, +1 day 2 hours]
- [ $Tracker_as_Calendar_12:trac_as_cal_priority, 5 ]
- [ $Tracker_as_Calendar_12:trac_as_cal_description, "I'm really looking forward to attending at this event." ]
{CODE}

Which produced, once applied, something like:

|| Summary | A big conference
Location | room 2.3 (15 seats)
Priority | 5
Description | I'm really looking forward to attending at this event.
Start date | 2014-05-28 12:58
End date | 2014-05-28 14:58
Created | Tuesday 27 of May, 2014 12:46:16 CEST
LastModif | Tuesday 27 of May, 2014 12:46:16 CEST
||

When clicking at edit, no start or end date are shown in the form, and the icon to open the popup helper to fix the dates is not shown either.

And then, in the wiki page to display items as calendar events ( http://xavi-9794-5254.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_12 ), this event is not displayed either.

{flash type="url" movie="display782" width="857" height="741"}

A CSRF never ending loop happened to me earlier today, on dev.t.o.
I had logged in chromium-browser to dev.t.o as user "xavi" (no admin perms).

I needed to log in with my other user "xavidp" (the one with admin perms), so that I opened a private browsing window of chromium-browser. I went to visit the same page I had visited with the standard user where I had to fix some perms of that wiki page ( https://dev.tiki.org/Wish%20Report%20Tpl ). Clicked at "login" link at the top bar, which sent me to https://dev.tiki.org/login , provided the credentials, and then I got the message about CSRF at the url https://dev.tiki.org/tiki-login.php :
{QUOTE()}Error
Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help.
{QUOTE}

Every time I tried (F5, visiting somewhere else within dev.t.o) and attempting to log in, I got the same CSRF error message reproduced, and I couldn't log in as user "xavidp".

I had to open a new browser (Firefox, in this case), and login as "xavidp" was successful.

I wonder what was happening.

I tried again, at the time of reporting this issue, and I got the issue reproduced again.

FYI: I had seen other weird CSRF false positives in other contexts in a 20.x tiki I use at work (behind a firewall). I 'll keep an eye open to add more details when I hit this bug again in other use cases. But there is something wrong still in the code in 20.x.

I have noticed there are db errors in https://tiki.org/tiki-syslog.php like Column 'commentDate' in where clause is ambiguous ...

What is that?
Can be fixed easily?

We need to decide on our branching & merging strategy.

Background info:
Many of the enhancements on HEAD have been backported to BRANCH-1-9. Most of the other enhancements have been done by Terence (teedog) -> ((tw:ReleaseProcess110))

Do we continue merges from 1.8 to 1.9 to Head?

Do we have devs assigned to merges, or do we ask each dev to do them?

Please see:
http://sourceforge.net/mailarchive/message.php?msg_id=11402375

More discussion needed here...

{syntax type="tiki" editor="plain"}
there is still that issue sometimes with the error undefined "thread sort mode" if you preview an answer before posting it at tw. forums.

It heppened to me again when attempting to reply to a thread with a comment already, and I previewed my post first before attemptint to post it.
When I clicked on post, I saw that message.

TW.o is currently using tiki5beta1 r26677

We need to decide about ((tw:DefaultSettingsChanges)) in 1.10

Some of the new features are much better than previous ones (ex new diff engine). People upgrading their Tiki could conserve their setting. However, new installs should take advantage of the new features.

A note should be added in tiki-install.php This must be low maintenance for Tiki dev team.

At https://dev.tiki.org/Preferences+report there is a link to http://demo.tiki.org/trunk/prefreport.csv

When clicking on it I get https://demo.tiki.org/trunk/tiki-install.php
Tiki Installer Disabled

Update: we don't have demo for trunk. Certainly due to PHP version requirement. {sign user="Bsfez" datetime="2018-11-03T17:33:09+00:00"}

At this link: https://tiki.org/Demo
Tiki18 is not represented, thanks for your attention.

http://info.tiki.org/demo promotes the demo sites.

And a lot of people use so they are __very messy__. After a while, they become unusable. And a bad impression of Tiki.

In the past, it was important to keep the demo sites for a certain time because people would use them to demonstrate bugs. But now that we have ((tw:show.tiki.org)), it's no longer important.

Ideally, there would be a pop-up or something indicating when the next refresh will happen. Otherwise, some people may have data reset while they are working on it. But in practice, this is quite rare. As long as hour of refresh is indicated on demo.tiki.org, it's good. So a daily refresh would be OK I think, but it could also be weekly.

Once the demo site is refreshed, the script to set the password to 12345 should be run. And users should not have to go through the admin reset routine. So beyond setting the password to 12345, the script should do what it takes for Tiki not to think the admin password needs to be changed. This is a problem we have on ((show.tiki.org))

dev.t.o (12.x): rating tracker items is half-broken

USer get the sensation that items from the dev.t.o bug tracker can not be rated any more, since when you click, the spinner never ends.

But if you refresh the page, the rating choice is shown (so it seems stored successfully, even if the spinner never ends and nothing indicates the user that the rating succeeded).

I don't know why but images can not be uploaded to a text area (bug tracker text area in dev.t.o). File gallery view is elFinder, and response is:

{QUOTE()}
Invalid backend response. data is empty
{QUOTE}

See screenshot:
{img fileId="580"}
---
Yes, fixed, thanks. {sign user="xavi" datetime="2013-11-16T17:03:37+00:00"}

dev.t.o 13.x: add some scrollbar at the top of wide tables in Bootstrapped themes, since they look as with less content for new users or unexperienced visitors

Example: see for instance
http://dev.tiki.org/tiki-tracker_view_history.php?itemId=5162

{img fileId="940" thumb="y" width="600" rel="box[g]"}

Column related to new content is not shown, and there is no clear indication that some more content is hidden in the right-hand side of that table.

New: A library has been found to solve this problem: [https://www.jqueryscript.net/other/Double-Scrollbar-For-Scrollable-Container-jQuery-DoubleScroll.html] . License is MIT.

for some reason, the echo on irc from teh new bugs reported on dev.t.o/tracker5 doesn't include the bug report title anymore (the first isMain field in the Tracker)

It was quite handy.... and I wonder if it's easily recoverable...

To reproduce:
* go to ((Make a wish))
* click at the icon to "Choose or upload images"
+ The pop up window entitle "Browse Files" will show up, with the elFinder interface.
* Click at the Button to upload files (disk icon with a green "plus" sign)
+ the focus goes to the search box, and the user can't do anything else than write into the search box. You can't close the popup window, nor move it, nor resize it.
* If you close the browser window, you'll loose all the information you already typed in the text area (it happened to me once :-/ )

Reproduced with Chrome and Firefox.

{img fileId="672"}
---
Retest:
{img fileId="699" thumb="y" rel="box[g]"}

dev.t.o: form to search for related-to bugs became recently broken

I could use it yesterday with no problems, while reporting this bug:
https://dev.tiki.org/item7133-CSRF-False-positives

which is linked to a couple other items.
If I edit that item now, I can't search for other items agains CSRF, for instance (while previously linked items are still linked there).

New bug reports do not allow to search for related items when you edit the bug report.
Something has changed in the last 24h? (some svn up? some config changes somewhere?)

For some reason, some edits to tracker items are lost in dev.t.o . I just noticed that.

I made (I thought I had made) an edit to this tracker item:
https://dev.tiki.org/item6668-Incorrect-integer-value-for-column-healed-at-row-1-when-adding-a-Tiki-Scheduler-task-in-mysql-strict-mode

Adding this extra content (below) to the "Description" field of the bug report:
{CODE()}
---
Tested again (using latest 18.x svn again), same failure, also with the task to do some list:execute action, which runs fine otherwise through the console.php command on a cronjob directly at the crontab level. {sign user="xavi" datetime="2018-09-10T08:05:06+00:00"}

I stop attempting to use Scheduler (Web interface) at all in my projects since I never managed to get it running, nor a simple task. Maybe it's not mysql 5.7 ready? {sign user="xavi" datetime="2018-09-10T08:05:06+00:00"}
{CODE}

After saving, I saw the new page reload, no reporting of succeful edit nor anything (no remarksbox at the top indicating that the edit was successful), and I saw no changes in the field "Description".

Tracker item history is shown as blank, also:
https://dev.tiki.org/tiki-tracker_view_history.php?itemId=6668

To speedup this site, delete any login which:

1- has not voted in tracker ratings
2- has not submitted, modified or commented a tracker item
3- no tracker item is submitted to them

In short, all logins which are not useful here at the moment. Logins will be recreated here at their next login via InterTiki anyway...

Current list needs a revision, especially before too many people start using: [tiki-browse_categories.php]


Please add your suggested categories as comments

User drop down menu now includes 7500+ users. This was a heavyload on the server so I removed them from the trackers.

IRC-Log 20050705
---
[22:38:53] <amette> ahum - it looks to me, that we loose data on tw.o and on dev.tw.o after site-updates - please have a look here: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=257&show=view&status=o&trackerId=5&sort_mode=f_41_desc&filterfield=26&filtervalue[26]=tracker
[22:39:36] <amette> luci added the solution as far as I remember (lastmod is empty) - later on I closed this item with solution Accepted and a modification to the solution

--- some stuff cut ---

[22:49:50] <amette> The thing with tw.o is, that I know exactly I edited a page - later toggg told me, that I didn't make the change, hm, well, yes, it was lost.....
---
The page in question is
http://tikiwiki.org/tiki-index.php?page=FindTikiExpert

No one can confirm that with their own Tiki.

I really don't know what it could be (site updates) - but it scares the hell out of me.... well, almost ;)

We have: ((tw:PO convertor for TikiWiki))

Should we change the way we handle language.php?: ((Research about different i18n systems))