Category: Error

When you set some expiry time for a group membership (through the admin groups interface), this information is stored in mysql table users_usergroups, and this is taken into account when you use ((doc:PluginMemberPayment)).

However, in other cases of letting a user join a group which has some expiry date set, that information (expiry date) is not stored at mysql table users_usergroups as expected.

Reproduced here:
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

You can also test with a few users already created:
u: foo1
p: 12345

or
u: user1
p: user1

Cases:
!!! a) Through usual Registration
if you set some group to be selected at registration time
You can register a new user to test case (a), and select either Group1 or Group2 at registration time (both have expiry date 2 days later):
http://xavi-9794-5946.show.tikiwiki.org/tiki-register.php

!!! b) Through Plugin subscribegroup
if the user clicks at ((doc:PluginSubscribeGroup)) (with perms and site config set up appropriately),
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#Plugin_subscribegroup

!!! c) Through Plugin MemberList
if the user selects to join him/herself thorugh ((doc:PluginMemberList))
(with perms and site config set up appropriately), or the admin join a user to that group
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginMemberList

However, looking at the user through tiki-assignuser.php?assign_user=foo , the right expiry information is shown.
http://xavi-9794-5946.show.tikiwiki.org/tiki-assignuser.php?assign_user=foo1

But if you use ((doc:PluginGroupExpiry)) (which looks for that date at table users_usergroups) no date is found and it reports back that the group membership never expires.
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginGroupExpiry_info

In addition, it seems that someone already noticed that type of issue, and this comment can be found in lib/userslib.php > function get_extend_until_info:
{CODE()}
(...)
function get_extend_until_info($user, $group, $periods = 1)
{
//use these functions to get current expiry dates for existing members - they are calculated in some cases
//so just grabbing the "expire" field from the users_usergroups table doesn't always work
(...)
{CODE}

---
Update {sign user="xavi" datetime="2016-05-27T14:38:26+00:00"}:
* this issue seems to be fixed in Tiki 15.x (as of r58705, at least). The 3 use cases work as expected (nice!). The extra code in 15.x would need to be backported to 12.x, I guess.
* Assign user to groups has got a regression in 15.x: you cannot see (nor even edit) the group expiry date through the standard user administration UI in 15.x: when you click in "add or remove from a group" in 15.x, you are sent in a modal to this type of url:
+ __tiki-ajax_services.php?controller=user&action=manage_groups&checked=foo1&all_groups%5B0%5D=Admins&all_groups%5B1%5D=Anonymous&all_groups%5B2%5D=Group1&all_groups%5B3%5D=Group2&all_groups%5B4%5D=Registered&offset=0&sort_mode=login_asc&numrows=25&modal=1__
+
+ and no expiry information is shown.
+
+ While in Tiki12, you are sent to:
+ __tiki-assignuser.php?assign_user=foo1__
+
+ This has been added as a new bug report, since it's another issue (regression):
+ [item5953]

Setting User Tracker id login and registration fields from Profile fails

See example in this profile:
https://profiles.tiki.org/User_Trackers#Group

{CODE()}
permissions:
Members:
description: members of the association
include: [ Registered ]
user_tracker: $user_tracker #and once this work, we need to tell the system about which field ID to connect to
user_tracker_field: $login # On a clean install, the following both should be at "1"
registration_fields: $profileobject:user_name$
{CODE}

names as indicated in the documentation:
http://profiles.tiki.org/tiki-index.php?page=Permission%20Management&redirectpage=Group%20Handler

At https://doc.tiki.org/VideoTutorial-2737-Basic%20Tiki%20Customisation
The autotoc is in the way and it have been turned off (set to on by default on the website).

It is not applied, on some screen it is breaking the page layout.

{img fileId="1293" thumb="box"}
{img fileId="1294" thumb="box"}

Still here on Tiki25 and Tiki26.
If you save a value for the "image_max_size_x" and "image_max_size_y" you can't use the upload modal dialog of the tracker field "file" to upload a file attached to a trackeritem.

''I had to reset the values manually in the database and then go the "edit" action of the file gallery and (re)save it. Trying to change the values from the HTML interface directly ended with a WSOD''

---

I've seen that happen again on a Tiki24.

It appears that if you fill ONLY one ends of the height or the width parameter when you upload a new file Tiki will get confused and in result the file will be corrupted.

Tiki should be able to resize using one end only. (max width or max height) and adapt OR we should force saving both parameters

---
On a Tiki 20

Setting only Maximum height of images in gallery in a gallery leads to a chain of incoherence and errors.

{img fileId="1303" thumb="box"}

I tried to set a value for width but it turned to be worst and uploaded files are corrupted and turned into .txt files.

{img fileId="1304" thumb="box"}
{img fileId="1305" thumb="box"}
{img fileId="1306" thumb="box"}

I assigned all permissions in a column on "Assign permissions to file gallery: File Galleries" assign permissions tab. Clicked on check box of "Anonymous" tab at the top of column and received this error:

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /home/fr55sx33/public_html/tiki_test_5.3/tiki-5.3/tiki-objectpermissions.php on line 506

Notice: Undefined index: perm in /home/fr55sx33/public_html/tiki_test_5.3/tiki-5.3/tiki-objectpermissions.php on line 506

Should be a quick fix for someone who knows the system; I sure wouldn't want my users to see this.

This is a new install of 5.3.

I put up a picture: {img id=112}

EDIT: The main problem was that doc/devtools/update.dogfoodserver.sh was interactive. It was fixed in commit r51249 by providing the default modelname to setup.sh. Also, the -n option to setup.sh has been deprecated in r51251, since it wasn't used anyways.

sh setup.sh -n should make the script non-interactive. It is still interactive and prompts for user input, though.

To reproduce:

sh setup.sh -n

There are some issues with dropdowns and tablesorter data with trackers.
Reproduced in a show.t.o instance (just after the bug item is created):
http://xavi-9794-5607.show.tikiwiki.org/tiki-index.php?page=Wants
u: admin
p: 12345


(1) Tracker item status displayed in a PluginTrackerList as dropdown has no values (this is fixed in Tiki14.x, it seems). Fixing in 12.x LTS will be appreciated.

Response: This is not backportable to 12x unfortunately. This ability sort and filter based on the image title wasn't added until tablersorter version 2.17.5 and Tiki 12 uses 2.14.4. But I have fixed as much as possible and it is now possible to filter using o, p or c in 12x

(2) Dropdown field. An item has no value for that field. How do you select those records with empty value? Could some filter like "empty/not empty" be added to the fitlers?

Response: I don't see an easy way to do this. Would suggest using the sorting to sort empties to the top, or in some cases setting dropdowns or range properly could capture empties (e.g., if they actually have a 0 value). Will ask the tablesorter developer for a fix.

(3) when the order of the fields in the plugin trackerlist doesn't match the order of the fields in the tracker definition, the results are unexpected: it seems to overrule the order in the trackerdefinition.

Response: after further discussion this is not an issue - the sort parameter needs to be set to y for columns to follow the order of the field parameter.

Thanks in advanced!

In a Tiki22 I have 2 trackers (orders, payments) with relation fields.

They may be one order with several payments (recurrent, monthly payment).
I have actually 4 payments per orders and that’s work ok but on a specific case I have more payment and Tiki throw errors.

{CODE()}
×
 Error
Indexing failed while processing "1268" (type trackeritem) with the error "Could not perform index modification: Data too long for column 'tracker_field_productsboughtPaymentId_text' at row 1"
×
 Error
Malformed search query: Could not perform index modification: Data too long for column 'tracker_field_productsboughtPaymentId_text' at row 1
×
 Error
The search index could not be updated. The site is misconfigured. Contact an administrator.
Could not perform index modification: Data too long for column 'tracker_field_productsboughtPaymentId_text' at row 1
{CODE}

{img fileId="1485" thumb="box"}

By nature relation shouldn’t be limited and able to handle many items.

~~#F00:__UPDATE__~~
It is plaguing and changing behaviour of other components.
In the screenshot below you can see many counter (plugin list count template) displaying a 0 instead of the real value even if the list plugin is set with a different tracker. There is a big chance the index become corrupted or not completed so I escalated.

The fields should be protected in a first place (avoiding using longer data than possible to use) and finally this field specific should be set to a relative high amount of data.

{img fileId="1486" thumb="box"}

Two misnamed files found in my latest download of the v197 .../lib/smarty/libs/internals/...

core.assemble_pgin_filepath.php
vs
core.assemble_plugin_filepath.php

core.process_coiled_include.php
vs
core.process_compiled_include.php

core.write_compied_resource.php
vs
core.write_compiled_resource.php

I recall this working in 6.x or so, so "tagged as regression".

Using (12.1svn): Abril 4, 2014. r50665

Sharing acccess rights, with token access, seems to be failing.
When using "Tell a firend" for a wiki page, as user with tiki_p_admin, there is a checkboxa message sending time, and the link in the email received by the destination emial contains a TOKEN hash inside. However, once clicked in that link in a browser as anonymous, the user see the message "L'accés a aquesta pàgina està acabat" (the access to this page is over).

When using Share, as user with tiki_p_admin to share a wiki page, I see the dropdown to indicate how many times to share access rights with that email. I shared for 3 accesses (the mas allowed in the admin panel, and thus, in the dropdown, also). The eamil that receives a message comes with a token hash inside, but still gets the message "L'accés a aquesta pàgina està acabat" (the access to this page is over).

---
u: admin
p: 12345
Homepage restricted to registered users. When SEFURL is off, sharing access rights with friends seemed to work as expected.
http://xavi-9794-5225.show.tikiwiki.org/tiki-index.php?page=Community+Members+HomePage
---
IT seems the bug was not solved in trunk by then (15.x currently), and a new fix was added by jonnyb in r58322. {sign user="xavidp" datetime="2016-04-14T12:54:16+00:00"}
---
Fix unconfirmed for me {sign user="xavi" datetime="2016-04-18T11:41:19+00:00"} in localhost with a snapshot of this site upgradeed to 15.x (rewrite rules do not work in show.t.o so SEF cannot be tested there). When attempting to view the site as anon. with the url (which includes the token param name and value), I get:
{QUOTE()}
Your access to this page has expired
{QUOTE}

Update June 22, 2016: This issue seems to happen still when any param is added to the url (page_ref_id=nnn - from structures, or fullscreen=y to prevent disclosing information from the side modules that the user has access to, besides the content that would like to be shown frmo the central column). {sign user="xavi" datetime="2016-06-23T07:32:05+00:00"}

Share feature was enabled. Unified search index rebuilt (or at least intended to do so, through tiki control panel)
I attempted to share one page with myself to double check a report with Share feature when perspectives were used, and I saw that it seems to be a broken feature in t.o for unknown reasons.
Example:
https://tiki.org/tiki-share.php?url=%2F202002-TAG-Meeting%3Fpage_ref_id%3D1328
I typed one or several emails, selected the options
* "Share access rights"
* "Receive notifications when the link is accessed"
and set
* Token Access Limit: 5

Send email: yes
(all other action buttons set to "no"), and I get at the top: "undefined"
No email is received by recipients.

t.o seems to currently run on:
Last update from SVN (21.0vcs): Sunday 15 March 2020 17:41:50 CET - REV 75908 (MyISAM)

1. We enter the name of the user at the corresponding input, Tiki offers us a list of users (here is 1) which we might be looking for:
{img fileId="1052" thumb="box"}
2. When we press "Share" button", the following error appears:
{img fileId="1053" thumb="box"}
3. We delete the parenthesis and whatever is inside of them:
{img fileId="1054" thumb="box"}
4. Press "Share" and the feature works well!
{img fileId="1055" thumb="box"}

This is an issue, since TIki offers users the "better way" offering users it knows about, but which doesn't work. Inter-tiki messenger on it's own is working properly, no error pops up at the very similar procedure carried out through the mailbox.

P.S. No php errors appear at the page bottom.

((doc:Share feature)) allows access 1 time less than value set in threshold.

Tested with sharing access 3 times to 2 users (sharing object perms), and it could only be viewed twice by each user.

Attempted to get it reproduced in a show2.t.o instance.

http://xavidp-1553-7326.show2.tikiwiki.org/
u: admin
p: 12345

Applied the company intranet profile. Enabled the share feature, and I was able to shaer a wiki page 5 times, and the email receiving the url with token was able to view that page 5 times. No more, no less.
No idea what happened the other day in the test we did Jyhem and myself on a Tiki 21 production site of myself.

{THUMB(id=23, url="tiki-browse_image.php?imageId=23")}Share page bug on BRANCH-1-10{THUMB}

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

I can no longer reproduce this behavior in 1.10. Please retest. Dave Thacker

I have encountered many problems with this feature when activating on dev.tikiwiki.org

A- The site becomes very slow...

B- ((TaskModuleTest)) page is almost totally blank.

C- Should there not be a feature setting for all of this?

Using the Shopping Cart profile on a fresh 12.1 SVN installation.

The shopping cart fails to recognize decimals, e.g. $2.50, in the product price.

Using the minicart NaN values sometimes occur. This may be the same problem.

---
After some more investigation, this may be a bug in the tracker loader for numeric fields.

My local system (Windows 7) is configured to use , (comma) as the decimal separator. It seems like the data loaded through the unified search, to fill the product list, uses the local machine definition, i.e. 0.55 is loaded as 0,55
I have not been able to locate the source for this.

Some versions of the Tikiwiki documentation suggest that a watch does not report a change to a web page that has been designated as a "minor" change. That does not appear to be the case for Tikiwiki 1.9.2.

If you ask me, the ability for a wiki user to make a Minor edit without bothering the "Watcher" crowd is a great idea and makes for a better community wiki dynamic.

doesn't save messages like "Hi" etc.

The 'Show page title:' check box in the Wiki Admin page seems to do nothing.

'Use page description:' toggles both the description and the page title together. Its both or nothing.

I don't know whether it's a regression or not.

There is a feature called "Show user's real name instead of login in autocomplete selector in trackers feature" (Admin/Config Wizard > Community General Settings). I ensured that the user field in the tracker is set to display realname also instead of username. The feature works when listing items through the tracker itself of plugin trakerlist, etc., but ....

__....it does not do the job at the autocomplete selector for the filtering of items__.

See it reproduced here:
http://xavi-9794-5892.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1&status=o&sort_mode=created_desc&filterfield=10&filtervalue[10]=user1&filtervalue[2]=&filtervalue_other=&filtervalue[3]=&filtervalue_other=&filtervalue[4]=&filtervalue_other=&filtervalue[5]=&filtervalue_other=&filtervalue[6]=&filtervalue_other=&filtervalue[7]=&filtervalue_other=&filtervalue[8]=&filtervalue_other=&filtervalue[9]=&filtervalue_other=&filtervalue[11]=&filter=Filter#

u: admin
p: 12345

This can disclose taxID's or other not-so-public information in LDAP setups.

{syntax type="tiki" editor="plain"}
Because now, after clicking "SVN Update", I get

Database Version Problem
Your database requires an update to match the the Tiki version; use the installer. Using Tiki with an incorrect database version will cause errors. If you have shell (SSH) access, you can also use the following, on the command line, from the root of your Tiki installation: php installer/shell.php

{img fileId="551"}


Also Composer needs running

On a trunk version installed by show.tiki.org

"Your database requires an update to match the the Tiki version; use the installer. Using Tiki with an incorrect database version will cause errors. If you have shell (SSH) access, you can also use the following, on the command line, from the root of your Tiki installation: php installer/shell.php"

Warning: PDOStatement::execute(): SQLSTATE[42S02]: Base table or view not found: 1146 Table 'marclaporte_11197_4698.tiki_preferences' doesn't exist in /var/www/marclaporte-11197-4698/lib/core/TikiDb/Pdo.php on line 75

http://marclaporte-11197-4698.show.tikiwiki.org/

{img fileId="395"}

{flash type="url" movie="display606" width="1042" height="316"}

Just upgraded to 1.9, and great work guys. There is a error in the menu in Article/ Admin types. The link points to tiki-articles_types.php.
The file in Tkik is tiki-article_types.php. Note one with the (s) one with out.

Thanks

Billy Jack