Category: 18.x

I have created a calendar in my 18.3 installation. This is to be the first calendar, others will follow. The first shall be world-readable, but writable only to registered users. The later calenders will also have read-restrictions to registered users, but at the moment they still don't exist.

So I started the calendar with individual permissions. The admin GUI of the calendar feature says that these individual object rights supersede the global rights, which had not been set.

But:
As a registered users I could read the calendar, but NOT create new events in it, although object permissions should allow me to do so. I had to enable this globally (!), which is not what I want to do.

Therefore it looks like the calendar feature only looks for global permissions, and not for object permissions.

Thanks
hman

The calendar feature does display the range it displays (I would like to be able to disable that, but that's minor. Perfect would be if I could disable to display of the year, or to disable the range in total. I find it to be redundant, because the calendar itself already displays that).

What's not so minor is that the dates shown there do follow the date display options of the Wiki, i.e. here in Germany date is followed by month.

But they are separated by slashes, which is not correct. It should be dots, and that is what is set in the preferences. All other date displays are correct (like the date of the last revision of a Wiki page), but calendar does not follow that rule.

Thanks
hman

Sigh. Yet another bug in calendar. In the main calendar window, when you are in the last week of this year's January (/tiki-18.8/tiki-calendar.php?todate=1611529200) the link to next week points to /tiki-18.8/tiki-calendar.php?todate=1612047600, which results in precisely the same week shown. Once you are at that point, "next week" will ALWAYS point to /tiki-18.8/tiki-calendar.php?todate=1612047600, so you cannot enter February by means of (repeatedly) clicking next week. This means you get stuck there!

The workaround is to pick (or enter) a specific date from February.

In February, the same bug strikes again: You cannot go into March by clicking next week.

hman

When you update a recurring calendar event (say, a yearly commemoration date) then you have a selection, to update only the current event or all events with the same rule of repetition (radio buttons).

If you check the latter, none gets updated. Not even the current one.

Oh, there are so many bugs in the calendar feature...

Thanks
hman

The calendar feature needs a deeper investigation and it has been done a lot of development around versions 21 LTS and 24 (trunk, future LTS).
This and possible further calendar bugs have to be reviewed, discussed and fixed in a broader context.

Regards,
Torsten

When feature_jscalendar is disabled, there's an error message upon saving an event (seems to be ok in Tiki21):

System error.
The following error message was returned:

Column 'start' cannot be null
The query was:

INSERT INTO `tiki_calendar_items` (`user`,`calendarId`,`name`,`description`,`status`,`url`,`lang`,`allday`,`start`,`end`,`priority`,`locationId`,`categoryId`,`nlId`,`lastmodif`,`created`) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
Values:

admin
1
gdfgdfgdf
dfgdfg
0
0
0
0
0
0
1576261805
1576261805
The built query was likely:

INSERT INTO `tiki_calendar_items` (`user`,`calendarId`,`name`,`description`,`status`,`url`,`lang`,`allday`,`start`,`end`,`priority`,`locationId`,`categoryId`,`nlId`,`lastmodif`,`created`) VALUES ('admin','1','gdfgdfgdf','dfgdfg','0','','','0',NULL,NULL,'0','0','0','0','1576261805','1576261805')

The calendar uses, when a new event is entered, a jquery date picker tool, to be precise it calls vendor_bundled/vendor/jquery/jquery-timepicker-addon/dist/index.html.

In this file I cannot find any localization tr() or tr in curly braces at all, thus all texts displayed like "Time" "Hour" and "Minute" are translated in no local language at all...

Not only that there is no direct access to the edit function (if you look at a calendar event, no tools icon is displayed, and when you click on an event, as I wrote in another bug report, you only get a huge mouseover containing some source code) - if you wiggle the mouse enough, you get another cursors, not the question mark. With that cursor comes a hyperlink to the edit function, but not as a clickable hyperlink. But you can copy the URL into the clipboard. If you past that into the URL bar of your browser, voilá, there is the edit function.

But it is broken.

First, it does not save everything you edit. If you make an event a repeated one, that will be forgotten. If you make an event one of a whole day, that will also be forgotten, but more so: A new, duplicate event will be created with no name and a subset of the events details...

Thanks
hman

P.S .: Because I cannot edit bug reports, I cannot enter the relation to the other bug report - because dev.tiki.org does not allow that to be entered in the first place, it can only be entered by editing a bug report.

Calls to plugins which are inside a call to the WYSIWYG plugin produce no output (which usually means that their effect is invisible). Some plugins, such as FOOTNOTE, have effects other than causing output, so calls to these may keep part or all of their effect.

This bug was introduced by the changes to wikiplugin_wysiwyg.php in {commit id=50752}. Tiki versions 14 to 18+ are affected.

The following call to WYSIWYG demonstrates:
{CODE(theme="default")}{WYSIWYG(use_html="n")}
This dummy content is visible.{FOOTNOTE()}Note which is invisible, but should be indicated by a number which is actually invisible{FOOTNOTE}
{GROUP(groups="Admins")}This should be visible for admins{GROUP}
{FADE(label="This should be visible")}Hidden{FADE}
{WYSIWYG}{CODE}


This happens because plugin_execute() calls ParserLib::convert_plugin_for_ckeditor() since ck_editor is true, and therefore returns an empty string to parse_first(), and therefore to parse_data(). That parse_data() has its ck_editor option true, since it is called by parseToWysiwyg(), called by wikiplugin_wysiwyg().

Unfortunately, the revision bringing this regression also fixes WYSIWYG edition. So going back to the previous situation breaks edition again. One can only choose between working visualization and working edition.

I believe the way to fix is to go back to parse_data(), but re-parse the plugin call's content differently when editing.

Example of url generated through the Profiles Wizard:
http://xavi-9794-6372.show.tikiwiki.org/tiki-admin.php?profile=Bug_Tracker_16&show_details_for=Bug_Tracker_16&categories%5B%5D=17.x&repository=http%3a%2f%2fprofiles.tiki.org%2fprofiles&page=profiles&preloadlist=y&list=List#step2

Example of equivalent profile applied through the Profiles Control panel:
http://xavi-9794-6372.show.tikiwiki.org/tiki-admin.php?ticket=4884aea2d5b951c86ed8b5fba540158a&daconfirm=y&profile=Bug_Tracker_16&repository=&page=profiles&redirect=0&list=Find

That show.t.o instance has:
u: admin
p: 12345

Through control panel there sems to be some __ticket__ param which is missing in the profiles wizard. Is this just the only thing which is missing?
---
UPDATE {sign user="xavi" datetime="2017-10-10T08:54:20+00:00"}
17.x svn ( -+Last update from SVN (17.2svn): Monday October 9, 2017 16:39:25 GMT-0200 - REV 64187 (MyISAM)+- ) is confirmed to suffer from this issue still. Please, pay attention to the fact that the button to apply the profile is shown, but when you click, the page reloads, and no profile is applied.
URL from profiles wizard is still like:
http://xavi-9794-6374.show.tikiwiki.org/tiki-admin.php?profile=Collaborative_Community_12x&show_details_for=Collaborative_Community_12x&categories%5B%5D=17.x&categories%5B%5D=Featured+profiles&repository=http%3a%2f%2fprofiles.tiki.org%2fprofiles&page=profiles&preloadlist=y&list=List#step2

u: admin
p: 12345
---

This is a regression from r((rev:61862)). The "$access->ticketMatch()" condition returns false, because the checkAuthenticity() method (called from tiki-admin.php) sets its property to false because a ticket is missing. And because the daconfirm request parameter is missing, the failure is silent.

__Pending re-test and backports to 18.x.__ {sign user="luci" datetime="2018-08-17T08:00:43+00:00"}

I can't change the language in the homepage using the switch language module when on a homepage when sefurl is active.

This is incomplete: I mainly wish to try if the wsho keys were moved when amette moved the dev.tiki.org server

Hi,
Following a doc example, on a fresh TW21 docker install from tiki, I create 2 trackers:
1st has fields: name, sports (linked, multiple values)
2nd has fields: sport
entering 2 sports and 1 name with 2 practiced sports for the dude.

Now go to tiki-ajax_services.php?controller=tabular&action=create
and if you click "Initialize this format with the current tracker fields" (http://127.0.0.1/tiki-ajax_services.php?controller=tabular&action=edit&tabularId=4&prefill=1)
you get an error 382 according to Apache:

Fatal error: Uncaught Error: Call to a member function getMode() on null in /var/www/html/lib/core/Services/Tracker/TabularController.php:700 Stack trace: #0 /var/www/html/lib/core/Services/Tracker/TabularController.php(104): Services_Tracker_TabularController->getSchema(Array, true) #1 /var/www/html/lib/core/Services/Broker.php(108): Services_Tracker_TabularController->action_edit(Object(JitFilter)) #2 /var/www/html/lib/core/Services/Broker.php(28): Services_Broker->attemptProcess('tabular', 'edit', Object(JitFilter)) #3 /var/www/html/tiki-ajax_services.php(51): Services_Broker->process('tabular', 'edit', Object(JitFilter)) #4 {main} thrown in /var/www/html/lib/core/Services/Tracker/TabularController.php on line 700

I tried using old export function and, instead of flattening the values to a comma list, it exports to CSV with "Array" in place of the linked values.

I also tried to make a tabular, then manually change field definition to "multiple values" and it threw an error about "Field mode" and it removes the field.

Maybe I do it wrong, how to export (and import) linked fields with multiple values?

It looks like mode is in working for item_list relating to a item_link field, but it only shows the first value

Best fix qould be with option like item_list field where you can specify format like %0,%1 or [%0,%1] or else, to choose the way to export and import nested values.

Thank you!

EDIT: Visit
http://philmzo-11996-7378.show2.tikiwiki.org/tiki-ajax_services.php?controller=tabular&action=edit&tabularId=1&prefill=1
for the problem on TW21

Once you have related something using a Relations field (or I imagine any other ways you can relate objects) you cannot remove the last related object, only change it to something else.

We had a similar issue with category checkboxes a while ago, it's because once none of the checkboxes are checked the request doesn't contain anything of that -+name+- so the field doesn't get updated.

Note: This for me is when the number of possible results is more than tiki_object_selector_threshold and the objects are shown as checkboxes - but others report it works ok... hmmm {sign user="jonnybradley" datetime="2019-05-07T14:59:15+00:00"}

It is not possible to create or name a page "Sandbox".
If I do there is an error:

{REMARKSBOX(type="errors" title="Error")}The Sandbox is disabled{REMARKSBOX}

Cannot upload images to file galleries on tiki.org anymore?

Wanted to upload simple little png screenshot but got:

Error
Data too long for column 'name' at row 1

Tried both the elFinder UI
and https://tiki.org/tiki-upload_file.php too

Under the uploaded preview thumbnail there appears also this message:
File upload failed: Forbidden

Ah, it seems only when I rename the screenshot file to something __really really short__ it works then:
__renamed Screenshot_2018-07-12 Roundtable Meeting 2018 07.png to Screenshot_2018-07-12.png__

The name should not be limited to such a low number of characters, should it? If yes, then it should state clearly before uploading that the file name has a limit to not confuse users...

Among several, there is one very big limitation of the shopping cart:

It cannot handle currencies! I wonder why no one saw this before (and I have to add, when debugging the translation of Tiki, it did not occur to me either). Cart must store the currency linked to all products. The currency of the user must be user-selectable (Of course, at the admin's discretion, the set of available currencies must be limited). We need to modify the data structure. The currency MUST become a separate field, and with that the price becomes strictly numeric (It could and should be discussed if we make that integer in the small currency units, but display it with the decimal comman/point inserted) and the currency should be strictly the three-letter ISO code, but a representation of that could be selectable (€ for EUR for instance).

If user currency and currency of any stock item differ, currencies must be converted. Currency conversion isn't easy. The first and easiest solution is having fixed conversion rates. These MUST be prominently and transparently displayed to the user, as they become part of the contract between the user and the admin/owner of the Tiki. Also, some sort of fee for currency conversion must be selectable by the admin (0 of course being the default), and it, too, must be prominently and transparently displayed.

When fixed rates have been established, the next level of comfort might be automatically set/updated rates. For that, we would have to find a reliable provider. Also, since all providers might for some reasons fail to supply data at any given time in the future, a default minimum and maximum rate must be selectable by the admin.

At first, I thought this could have been overlooked because of a domination by the US, but then it crossed my mind that even Americans have the need for currency conversion, because they got US and Canadian dollars, and when they sell internationally, also Australian and New Zealand dollars...

In Europe it is much more complex. Most countries have the Euro, but not all. Great Britain does not, but now it's not even part of the EU anymore. In the German speaking countries we have Euros (Germany, Austria) and Swiss Francs. Even though Switzerland is also no member of the EU, the fact that a large portion of Switzerland speaks German leads to Swiss users using German Tikis, and vice versa.

When you go to Products (the main shop) and click on a product, you get the products's page (Product), but that does not have a backlink to Products. Ideally it should backlink to the Products page that lead there (could be paginated), but a generic backlink to Products would be sufficient. This breaks the user experience that the backlink arrow leads back to all pages that linked to the current one. The browser's back button, of course, still works.

(CART is missing in the drop-down menu to indicate the feature to which this bug report relates to).

The localization of CART seemingly stopped right in the middle? Half of the GUI is localized, the other half is still in English.

That's no problem for me, but might be for others. And it's just inconsistent.

Also, some dialogs seem to be hardcoded in English, and remain in English even when the Wiki is set to, for instance, German: "No outstanding payments found" in the main screen of payments...

Thanks
hman

__DESCRIPTION__: We have deployed a platform with CAS JASIG, TIKIWIKI and JOOMLA. We have an issue with users that are already logged in JOOMLA and try to access TIKI.

__ISSUE__: CAS Autologin feature fails to complete.
_SINCE WHEN_: This issue has been at least since version 14.x
_PROCEDURE THAT FAILS_: If i try to access a restricted resource without explicitly login before.
1. Tiki redirects to CAS SERVER __(NORMAL CASE)__
2. CAS SERVER redirects back to Tiki __(NORMAL CASE)__
3. Tiki redirects back to TIKI main page __(NOT NORMAL)__

_NOTE_: The Autologin functions well only when we explicitly access _tiki-login.php_

On a fresh install with version 18.1

-I want to use Categories to restrict access to images and files

To do that, I created a category "CAT_1" and placed "IMAGE_1.JPG" in that category.

Then I created a group "GROUP_1" (inherited from Registered) and placed "USER_1" in it.

Now about permissions:

I removed ALL the "Files Galleries" permissions from global permissions on both groups, Registered and GROUP_1.

When I did that, USER_1 stopped being able to see the files on the wiki.

Then I changed CAT_1 permissions (according to the page, it overrides the global permissions) to ALLOW USER_1 and Registered to see the Files Galleries. I was expecting to see the file IMAGE_1.JPG that is in CAT_1, but USER_1 continues to see nothing.

I am including tiki_p_download_files when I make changes on the permissions.
I am clearing the cache after the changes.

I expected to allow USER_1 to see only the images under CAT_1, but when I make the changes above, it stops seeing al the files

If you create a new sub-category, for instance for Tiki Cart, the name of the category will get translated, if you want it or not. It's compulsory.

For instance, I wanted to add sub-category to Products named "button". The Wiki shall be for the use of a non-profit organisation, and those typically have buttons (to attach to your clothing).

Tiki Wiki 18 immediately translates "button" to "Schaltfläche" and creates the sub-category with just that translated name, which is pure and utter nonsense. Side note: Besides the fact that an automatic translation is definitely unwanted here, it's perfectly wrong also. Button is ambigous can mean the sticker your your clothing or something to click on in a GUI. And in German these have different translations.

Tiki Wiki chose the GUI meaning, which is wrong. And again, it's totally unwanted. So I assume this is some internal malfunction that produces a translation (localization) somewhere in the logic that parses entries here.

"button" seems to be a reserved "magic" keyword, but there should be no reserved keywords when it comes to names, because this means that names are not transparent, but opaque.

It is really impossible to create a sub-category named "button" and thus to sell buttons with Tiki Cart...

When a comment contains a line too long to fit in the viewport, that source line is generally displayed correctly by splitting it into multiple output lines. But it seems that in certain comments, like the 2018-03-05 09:20 comment [https://dev.tiki.org/item6130-Forums-Posts-can-be-rated-results-in-Request-URI-too-long-error-when-enabled-and-user-tries-to|ticket #6130], automatic text wrapping is too late, which causes a hidden overflow of text at the end of full lines.

This affects an installation of Tiki 15 using a custom theme (Foncierpedia).

This does not affect most comments. 2 installations of Google Chrome 64 on 2 tested are affected. Firefox seems unaffected, while Internet Explorer 11 seems most unaffected, but still a bit affected.

The name 'Tracker Tabular' does not mean anything to non-IT people.
I still can't figure out why it is called this, it is confusing.

If it is "an advanced import/export feature for Trackers" than call it that:
Tracker Import-Export

Tiki smileys are so 90s... It look very bad.

:)
;)
(:santa:)
(:twisted:)

Really ?

--drsassafras begin--
This seems related to : https://dev.tiki.org/item6191 and https://dev.tiki.org/item6189

I looked into the issue not so long ago. Almost all browsers now support emoji. Desktop and mobile. If we enable the saving of emoji in our database, they will all show nicely, and will always be kept up to date with the OS/Browser.

A little emoji selector could be made for users who dont have a emoji keyboard set up, and the existing similes used here could be integrated.

Although, it might be easier to replace the emoticons with new ones in the mean time.
--drsassafras end--

See first the box saying "Even better" below.

"__PluginTogether should replace the url associated with the Edit page button so that co-editors are automagically offered to go to the session with collaborative edition instead of the warning of edition conflict__" (was --"Clicking on PluginTogether on a wiki page should provide a CoEdit button next to Edit with the right url for all."--)

This would be useful for taking meeting minutes collaboratively in the ((tw:TRM)) and ((tw:TAG)) meetings, both which take precious time from some active tiki community members but with little time to do things properly (wasting precious time in this note-taking task instead of being able to invest it in other areas requiring their help too). {sign user="xavi" datetime="2017-01-12T13:09:23+00:00"}


I've been trying to use tiki for many semester with my students at uni but I can't get them to use it with realtime collaboration with ease, so that they move to googledocs.

This minor usability change would be probably enough to convince teams to use tiki realtime collaboration feature with plugin togetherjs.
Like ourselves when taking notes on a roundtable meeting, or tiki admin group meeting, etc.
{BOX()}
__Even better__
Even easier for the end user would be to just offer a user that sees the concurrent edition warning box, a link to carry on and convert the session into a togetherJS session in which both users continue writing together. In the backend, tiki would probably:
# A new general preference should be added for this new behavior to be enabled
# when user A clicks at edit a wiki pageFoo, the url that would be created by PluginTogether is stored in tiki mysql tables somewhere, with a semaphore/flag or similar so that tiki knows that this page has been started edition and the url to allows others to go into the same edition session collaboratively.
# when user B clicks at the __Edit__ button of the same pageFoo, while still being edited by userA, userB sees the warning of edition conflict unless userB accepts to request to userA to enter into the collaborative session.
# If userB accepts to request that coedition to userA, then UserA would see some warning about that request from userB in some popup/modal/or similar, with the option to accept and get his edition saved and restarted as online collaboration among both, or reject the request, and keep writing himself alone in that page.
# therefore, save the edition in place by user A (the one that started editing the page first)
# reopen that page for edition for user A with te url adapted to the togetherjs session, and
# send user B to the edition session with togetherjs (or alternatively, show userB the same link to open the page for edition).
# if userA accepted userB to write together, they both are working with TogetherJS on that page. And in that case, when other users such as userC clicks at edit the wiki pageFoo again, userA gets the same message requesting to confirm to accept new users getting the collaborative session, and when accepted, since the TogetherJS is already on, there wouldn't be any need to restart the edition session with togetherJs since it would be already in that mode.
{BOX}

---
This is currently partly working in 21.x LTS {sign user="xavi" datetime="2020-04-01T10:32:07+00:00"}:
* user is sent automagically to open the session without "Warn on edit conflict"
* ... __BUT the together session fails to display the other users being there editing the page concurrently__:
** therefore, a new version is saved, without noticing that the versions will not be seen by each other: -+Edit Conflict triggered+-.

To reproduce the updated problem info:
Come here with two different browser engines (or one in provate browsing and hte other in normal, as usual to test this feature):
http://xavi-9794-6160.show2.tikiwiki.org/tiki-index.php?page=HomePage
user1:
u: admin
p: 12345

user2:
u: user
p: 54321

# Click on button of the side module "Co-Write with TogetherJS"
# Edit homepage as user1 (admin) in browser engine1 (e.g. firefox)
# Edit homepage as user2 (user in browser engine2 (e.g. chromium)
** accept the popup asking to join session

problem triggered: none can see that the other user is editing the page, saving, moving elsewhere, etc.

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

It would be good to make the 'User' (i.e. user name) a required field when adding a new Tiki User (Admin Users)

Recently, I tested adding a new user without this (left blank), but added the password (2x) and an email. Tiki went the the next step, 'Confirm adding new user', then went to the full user list. Of course it was not visible anywhere in the full list of users (only one page, under 10 users total).

Also, it might make sense to change the name from 'user' to 'user name', or even more direct 'login'.

br,
Mike