Category: Consistency

Update email in mail notifications list when email replaced in user account

I did change my email in my account settings at t.o. That email was transfered to dev.t.o properly.
And my mail notifications in t.o where updated properly. __However, the mail notifications in the slave sites (from the same intertiki network) did not get updated__

I don't know how to fix this one myself.

Icons are defined in the sql schema. therefore the logic to display the icon needs to be adapted to use
{CODE()}
{icon name="foo"}
{CODE}

instead of the img html tag.


See it reproduced here:
--http://xavidp-1553-5651.show.tikiwiki.org/tiki-admin_menu_options.php?menuId=43&offset=0&sort_mode=position_asc&optionId=195&maxRecords=25#contentadmin_menu_options-2 --
u: admin
p: 12345

----
Confirmed issues still exists in Tiki18.0 {sign user="xavi" datetime="2018-02-05T19:39:10+00:00"}
---
Re-reproduced in 18.2svn {sign user="xavi" datetime="2018-04-03T16:08:42+00:00"} in a new show.t.o instance (even if the issue is more easily shown when upgrading a previous tiki site where those settings where more easily ticked):
Login as admin here:
http://xavi-9794-5783.show.tikiwiki.org/tiki-admin_menu_options.php?menuId=42
u: admin
p: 12345

You need to ensure that the menu is not using bootstrap but css, plus the setting enabled to use icons for menus (done already in the show.t.o instance)

Cheers

{syntax type="tiki" editor="plain"}
When upgrading Cartograf from Tiki 21.x (possibly 24.x?) to 27.x we found that "[https://gitlab.com/tikiwiki/tiki/-/merge_requests/2170|duplicate cascade]" wasn't set on the child trackers to duplicate features when a map is duplicated.

This used to happen always before this option was added but it would be nice, espescially if "Cascade actions" is set to "All" on the ItemLink fields, then -+duplicateCascade+- should be set to "Yes" (1).

~~#f33:__Update!__~~

#~~#f33:Unzip Zip Files (Batch Upload) is Broken for Windows and CentOS~~
#~~#f33:Adding Multiple files one at a time, then uploading in-batch is broken __ONLY for Windows XP__ (CentOS works).~~

System Used:

1) Windows XP
XAMPP
Tiki 4.0 and 4.1 (12-15-2009)
IE 8 or Mozilla FF 3

2) CentOS 5.x
Tiki 4.0 and 4.1
IE 8

In Tiki 3.x it is possible to upload multiple files at one time to any file gallery by one of two methods:

1. Keep clicking the "Add" button and add select multiple files for uploading. Then finally click the "Upload" button.

2. Select a zip file to upload, and check the "Unzip" checkbox.

~~#f00:__In Tiki 4.0/4.1 this feature is broken.__ ~~ The resulting behavior is that the upload progress-indicator (spoked-wheel animation) runs forever, and the Apache server must be restarted before the user can continue to upload any other files after the failed attempt at multiple-uploads.

~~#f00:__For purposes of data/file migration to Tiki, this is a serious issue.__~~
I'm not much of a PHP programmer, and I suspect other Tiki users are not either...so checking out the latest code from the head of a branch is probably not a great work-around (in general).

https://doc.tiki.org/tiki-tracker-update_item?trackerId=20&itemId=2735

I try to upload a file (file is uploaded but not assigned and show error)
{img type="src" src="https://tiki.org/dl1996?display" thumb="box"}

I hten use the browse file button (the file was uploaded even if tiki says otherwise) and it end with a weird redirection while the tracker edit was saved.

{img type="src" src="https://tiki.org/dl1999?display" thumb="box"}

If you change a listing, like on the Wishlist, and change sorting order, the URL gets an additional mention of the sort order.

But it's reversed, compared to the actual setting. So if you want to sort the Wishlist by modification date, descending (which IMHO should be the default), so the latest are listed at the top, the URL states

{CODE(Colors="Tiki")}
https://dev.tiki.org/Wishlist#sort_mode=modification_date_asc
{CODE}

ASC=Ascending. If you change sorting to ascending, the URL states _desc...

On a fresh install at Admin -> Log in I enable "Users can register", I uncheck "Validate new user registrations by email" and I set an URL for the field:"URL the user is redirected to after account validation"

So validation is not done using the email link but is done right away after validating the register form.

I create a wiki page: mysuccesspage and tried with page name, a relative path tiki-index.pgp?page= mysuccesspage and an absolute path: http://mysite.com/tiki-index.pgp?page= mysuccesspage

I’m redirected to the default registration page.

I enabled back "Validate new user registrations by email"to check and it worked.

----

I created an instance to demonstrate:
Setting are good : http://bsfez-11581-6095.show.tikiwiki.org/tiki-admin.php?page=login
Success page exist : http://bsfez-11581-6095.show.tikiwiki.org/tiki-index.php?page=success

The Webmail and Groupmail feature uses old Tiki icons (or plain text).

They should use the last Tiki icon generation (FontAwesome) and text links should be modernized accordingly.

Tiki User credits: You can create Credit types (which you need to do, because the feature starts empty), but once created, you can never admin/edit them. Not even delete them. This is so basic a function, that I do not open this as a feature request. It is a bug.

Btw., there is no documentation to be found about this feature...

Using 2.0beta code, afaicr.

There are two different users (from two people) in a site: "Xavi" and "Xavier"

This user (which is me)
http://intercanvis.net/tiki-user_information.php?view_user=Xavi

shows some data from the user "Xavier" (the data from the group tracker, afaik):
^
Nom: xavier
Cognoms: rocabert argila
Usuari: xavierrocabert
Telèfon: 932372798
Barri / Població: barcelona
^

As you can see, this information belongs to this other user:
http://intercanvis.net/tiki-user_information.php?view_user=Xavier

Using a Tiki at tiki-admin.php?page=login you can set the user to receive an email to validate its account or as welcome.
This work fine.

You can also use a tracker plugin in a wiki page to fill a tracker item and set that this include a registration.
However the user then doesn't receive any email or validation email.

There is a parameter "Validate users" (y/n) that override only part of the process:
"Here one can overrule the default validate users by e-mail preference"

Setting to Y, users are validated automatically.
They don't receive the registration validation email or anything else (all process is overruled) .

Setting to N, users are not validated.
But, they also don't receive the registration validation email or anything else (all process is overruled) .

{syntax type="tiki" editor="plain"}
User wizard (accessible via -+/tiki-wizard_user.php+- ) needs some love to get harmonized consistent look and feel (UX) with the Admin Wizard ( -+tiki-wizard_admin.php+- ).

It has some old ugly icons (they should be replaced by FontAwesome icons) and broken GIF image references when you go through the steps of the wizard.

Please have a look at TPL files of tiki-wizard_admin.php for example how it should be done and harmonize.

Username rename in trackers doesn't work when there are multiple values.

No nearer clarification - just heard about it.
I can well believe it though - not digged into code.
But it's not consistent! And not good over all.

{syntax type="tiki" editor="plain"}
The problem is summarized in 2:

1) The category perm checking for individual tracker item always happens no matter what.

2) Even when it makes sense to check for category perms, the filter appears to not take into account specific tracker perm, because trackeritem is a "different" object from tracker.

The problem is in the following piece of code in trackerlib.php

{CODE()}
function filter_categ_items($ret) {
//this is an approxomation - the perm should be function of the status
global $categlib; include_once('lib/categories/categlib.php');
if (empty($ret['itemId']) || $categlib->is_categorized('trackeritem', $ret['itemId'])) {
return Perms::filter(array('type' => 'trackeritem'), 'object', $ret, array('object' => 'itemId'), 'view_trackers');
} else {
return $ret;
}
}
{CODE}

I switch a Tiki18 to a Tiki19.

During the install on the database step, I had a warning about "UTF-8 encoding" while my tables were properly upgraded to utf8mb4_unicode_ci.

Following the links to the doc doesn’t really help
{img fileId="1240" thumb="box"}
---
On a second attempt (local) I didn’t upgrade previously the table and applied the database upgrade. After upgrading the database I checked my database (phpmyadmin) most of the tables were utf8mb4_unicode_ci while a few (see the list below) were still UTF-8 unicode;
tiki_acct_journal
tiki_acct_stack
tiki_banning

The database upgrade process ended successfully but with error report:
{CODE()}
Upgrade operations executed successfully: 668 SQL queries.

Operations failed: 6 SQL queries. Display details.

During an upgrade, it is normal to have SQL failures resulting with Table already exists messages.
ALTER TABLE `sessions` convert to character set DEFAULT COLLATE DEFAULT Table 'tsaharoniki_tiki19.sessions' doesn't exist ALTER TABLE `tiki_banning` convert to character set DEFAULT COLLATE DEFAULT Invalid default value for 'date_to' ALTER TABLE `tiki_acct_journal` convert to character set DEFAULT COLLATE DEFAULT Invalid default value for 'journalDate' ALTER TABLE `tiki_acct_stack` convert to character set DEFAULT COLLATE DEFAULT Invalid default value for 'stackDate' ALTER TABLE `tiki_banning` CHANGE `message` `message` text COLLATE utf8mb4_unicode_ci Invalid default value for 'date_to' ALTER TABLE `sessions` CHANGE `data` `data` text COLLATE utf8mb4_unicode_ci NOT NULL Table 'tsaharoniki_tiki19.sessions' doesn't exist

If you think that the errors of a patch can be ignored, please check the checkbox associated to it before clicking on continue.
{CODE}

I refreshed and they were no more errors.

On open suse 11.0/1/2 using profile:intranet The calendar feature does not seem to show the newly created calendar.

the SORT plugin works perfectly when set up using the standard wiki editor eg

~np~{SORT(sort="asc")}~/np~
rabbits
cats
dogs
tigers
zebras
pigs
lions
horses
~np~{SORT}~/np~

produces:
{SORT(sort="asc")}
rabbits
cats
dogs
tigers
zebras
pigs
lions
horses
{SORT}

But if the same 'code' is set up in the wysiwyg editor it does 'sort' the list but does not display the result on separate lines ie it produces:

cats
dogs horses lions pigs rabbits tigers
zebras

{syntax type="tiki" editor="plain"}
The WANTEDPAGES plugin uses the tiki_links table. This table will store an entry if a page links to a page with a CamelCase name.
When listing the wanted pages, it is normal to ignore links to CamelCase page names from tiki_links if WikiWords are disabled, since strings like "ClickHere" are not actual links. However, this is wrong if the link is explicit, say ((ClickHere)).

This happens on trunk r20832.

It is possible to watch for new articles here: tiki-user_watches.php

So why not add an "eye" in view articles and list articles?

I do not receive notifications when watched tracker item is commented. Is it a setting or is it a missing feature ? Is it a consistency bug when wiki pages allow notifications on new comments ?

{syntax type="tiki" editor="plain"}
Plugin invocations with no arguments (e.g. SUP) when edited with the wikiplugin_editor, and without the hack in place get name value pairs such as:

$family
each
clean
associate
link
contains
extend

(see attachment)
{img src=tiki-download_item_attachment.php?attId=183}


This seems to come about from lib/mootools/mootools.js

Affects tikilib.php and tiki-js.js

Workaround is in the code. Grep for "//TODO HACK: See bug 2499"

When importing new fields using the tracker import "Import Fields" button, they all need a different FIELDXX text.
If they have the same [[FIELDXX] line, only the last one is imported and all the others are discarded.

This is unexpected because the field number is ignored anyway unless "Preserve field IDs" is checked below.

This is a UX failure because the common use case is
* export a field
* duplicate and adapt in a text editor
* import new fields

With version 2.2, normal and OpenID login enabled, and the modules "since_last_visit" and "since_last_visit_new", they don't reset when using OpenID login. When loging in with the normal login, those since last visit changes are reset.

13.x: Comments can't be posted in some pages of the Featured Profile "Collaborative Community 12x", such as the homepage for registered members, or newly created pages such as "Subject 1", etc. Doing all that as admin.

See screencast where the issue is reproduced.
https://www.youtube.com/watch?v=7-OI5GCY4qQ

{youtube movie="https://www.youtube.com/watch?v=7-OI5GCY4qQ"}