Category: Edit interface (UI)

suggested by r1 on #tikiwiki
http://24ways.org/2007/capturing-caps-lock

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).

dev.t.o 14.x: only the last item in the multiple selection combo box is stored for this tracker item

See it reproduced here:
https://dev.tiki.org/item5464?from=Structure

Edited this item as user "xavi" (without admin rights, in case it matters), Selecting some other categories in the combo box for the field "Category" or the field "Version": => only the last category (or at least, only one from all the ones selected) is stored

I uploaded a screenshot to a tracker item ([item5044]).

I tried to Draw on it the url
provided by the edit icon after the image:
http://dev.tiki.org/tiki-edit_draw.php?fileId=672

And I lost control over the popup window. I can't click anywhere to gain control over the popup.

{img fileId="673"}

Related to [item5044]: "dev.t.o: Can't upload images with elFinder"?

I attempted to use ((doc:PluginPivotTable)) in a new page in dev.t.o: ((Bug report evolution))

# I first wrote ~np~{pivottable}~/np~ in the wiki page and saved (to check whether there was going to be some helper to find the right compulsory params that where missing (tracker:5 assigned to some param name, which I didn't remember)
# then I edited again the wiki page, and clicked at the plugin toolbar icon to get the popup helper for pivottable.
** this requested me to indicate the first compusolry field, which offered to me to select some wiki page name, but not the right param content for the data source (tracker:n o activityStream). __First error/regression__ (it used to allow typing any text there, afair, but it currently deletes what the user types since it doesn't match any option from the list of wiki page names shown).
** I selected some page name, so that I could get the param name correctly written in plugin call in the textarea of the wiki page, to fix the value assigned to that param name manually, while also writing to text in the body of the plugin textarea while still in the popup helper. But when I attempted to accept to get the syntax inserted in the wiki page, I got this error message:

-+Plugin edit failed+-

Oups, bad user experience. Looks like as if it was some experimental feature, while it has been there for years across many versions.

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

Several (all?) of my recent edits to ((Tiki18)) page here in dev.t.o send me (user "xavi") to the dev.t.o homepage . That's new, it didn't happen to me months ago (nior in earlier tiki versions).
Regression?
---
Update: reproduced similar issue in trunk (from yesterday) {sign user="xavi" datetime="2018-09-28T09:22:41+00:00"}

We have been experiencing in our team at work several issues while attempting to use Tiki Diagrams in production in Tiki 21.x LTS

There might be 2 related (for the end user) issues. It seems as if some ticket expires too soon and some error related to CSRF is shown. Maybe after editing the diagram for more than 20 minutes or so (even if Tiki is set to remember the login for days or weeks, which seems to work when we are not using the diagram feature).

Diagrams are created to store their contents in a wiki page (because in file gallery we face some other issue still, as reported in [item7192|another bug report])

2 error messages are shown in similar conditions (unclear yet the exact difference; these reports were sent by work colleagues of mine, so far)
Error message 1:
{QUOTE()}
"An error occurred, please try again.
Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help."
{QUOTE}

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

Error message 2:
{QUOTE()}
"An error occurred, please try again.
Potential cross-site request forgery (CSRF) detected. Operation blocked. Ticket has expired. Reload the page"
{QUOTE}

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

In case it matters: the https certificate seems to be not recognized (by the browser used to reproduce the issue) as valid.

When users change the new ''style'' parameter, the plugin asks for approval.

This is a usability regression on sites with editors who are not power users and who are not given approval permissions.

This is an improvement for sites with editors who are given approval permission.

I attempted to upload a simple image to a doc.t.o page (it seems to be using 19.x and elfinder) and I got error message about CSRF
{QUOTE()}
Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help.
{QUOTE}

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

I had to disable elFinder to allow uploading images to doc.t.o.

Feel free to re-enable elFinder feature in doc.t.o anyone once it's confirmed to have been fixed.

Duplicating events in calendars is broken on 1.10svn right now (April 17th)
If anybody wants to test (to reproduce it) on site, I can grant you account details here (a production site):
http://moviments.net/cursos/tiki-calendar.php

I tried editting this, and clicking to duplicate button (to make a new event from the edition of an existing one; I thought I could do that on previous 1.9.x sites), but no success:
http://moviments.net/cursos/tiki-calendar_edit_item.php?viewcalitemId=64

I tried also creating a blank new item, fill in the form for the calendar item, and instead of cliking on the "save" button, click on the "duplicate to" and select the calendar where I wanted to duplicate this item to.

After the click to the button, I saw another item in the edit event form (on the same browser window), and in other tabs, I could see that no new event was added, neither for that calendar selected or any other on the site.

It's a pity that calendar events can not be duplicated on 1.10svn, since it's a very useful feature for high load tiki sites. (like when adding 10 sessions of a new course, all of them with similar details except for the day of the month, etc.)

{syntax type="tiki" editor="plain"}
In RC2 they made some changes to the edit-help (the now blue circle with a question mark).

When you open up the help and go to full screen mode, the text is un-readable while using the Darkroom theme.

If the width of an edit screen is temporarily increased - which is often very useful - then it underlaps a right hand column (if there is one)

This seems to happen in all edit screens, including this tracker edit screen where this 'wish/bug' is being entered.

I've tried to fix this with some custom css ie adding/increasing a z-index parameter but haven't managed to find a successful fix

fixed in 57795 - thanks Gary

Using strasa.css in demo.t.o/11.x (reproduced else where also)

Log in as admin
Edit a wiki page,
click at a tool in the toolbar (help icon clicked in the screenshot below)
popup box is shown under the text area, no button are shown, most controls are hidden, etc.

See screenshot

{img fileId="288" thumb="y" rel="box[g]"}

There is a z-index problem with the edit help modal when editing a calendar event. The help modal displays behind the edit event form.

A related still-open bug report is at [https://dev.tiki.org/item5788-Z-index-issue-in-tiki-calendar-php].

There might be some sharp edge somewhere with the new ((doc:PluginGanttChart)) or with the profile to showcase it.

Editing a Gantt Chart through its own UI shows missleading messages after resizing some bars: some success message in a remarksbox, as well as another remarksbox reporting some sort of error:
-+Error: The following mandatory fields are missing: Dependencies+-
---

Reproduced here:
http://xavi-9794-7119.show2.tikiwiki.org/tiki-index.php?page=Sample-Gantt-Chart
u: admin
p: 12345

See also:
{img fileId="1309" thumb="box"}

---
The error message is legitimate: field dependencies was set to be "mandatory", and it seems as if that the jquery gantt editor ui doesn't expose this field to Tiki, therefore tiki complains that this mandatory field is missing. Or well, this is my own "educated guess" on what might be happening. I've removed the "mandatory" value in that field in the profile at profiles.t.o (but not in the show2.t.o linked to this bug report).

So that the problem here might be that the success message is fake? (just another educated guess) {sign user="xavi" datetime="2019-08-14T22:04:34+00:00"}

I did not choose versions feature is missing, as it is not a part of any version as far as I know, and I thought it would just seem funny to have every single version listed above per " If it’s a feature request, indicate the version in which the feature is missing."

I think it would be wonderful to have an editing interface that can be assigned per user group. As it is now, all users share the same Wysiwyg and Syntax editor.

It would be very convenient to have an editor with tools configured per user group. The reason being is, I may not want our users to have access to many of the same tools as I would want to have on my editing tool bar.
Also, it would be nice to present our users with a stripped down tool bar as to not overwhelm the average user. Or some use cases, give the users all the tools they need, yet I may not want those same tools on my editing tool bar.

So, editing tool bar per user group?
Thanks for reading!

When a user's preferred language is set to Simplified or Traditional Chinese, that user will notice that upon editing a page the Wysiwyg editor won't complete loading. Other preferred languages I tried including English, Japanese and Dutch do not have this problem.

To see the bug:
- Go to [http://kong-11768-5699.show.tikiwiki.org]
- After show login, login to tiki as usr: admin and pwd: 12345
- Menu select: Wiki文档 -> Create a Wiki Page
- Fill in any name for wiki page to be created
- Click 创建文档 button
- Confirm language
- See the editor is loading for ever...

I have taken a snapshot just now of the show db, just in case.

While trying to insert a file or image into a tiki page, the editor user interface will not load that image using "Browse Gallery" when that file is clicked on.
Please see show instance for 19.x and the same issue is present in tiki 20.x

{syntax type="tiki" editor="plain"}
I have a problem, i dont know how fix it
In tiki4.2 in wiki pages (others doesn’t show this error) editor wysiwyg, does insert an image but it change the code with this code
{…}, (I know cos I saw it , in the html view)
But when I save it doesn’t recognize the image, If I return to the html editor and change the {…} With <…>, it works

Somebody can help me??
(:wink:)

If you are in a site with some "documentation" activity (a bunch of images already in the default folder), it's not easy for the end user to insert the image he/she has just uploaded to Tiki thorugh the toolbar icons/actions.

With the former file gallery interface to upload a file, you see the thumbnail or icon of the image/file just uploaded, so that it's very easy to find it and click on it to get the corresponding wiki syntax inserted in the text area, so that the file is used within the text.

With elFinder, this simple task becomes difficult, annoying, and time consuming (plus irritating at some times, if you can't seem to find the image you have just uploaded and you KNOW it's there somewhere).

Usual case (can be easily reproduced in doc.t.o):
# Log in doc.t.o
# Edit a documentation page
# Click at the toolbar icon to insert a new image from your local harddisk. elFinder interface is shown.
# Click at the icon to insert the file from your harddisk. Select your file, upload it.
# Once the file has finished uploading, you have no clue where the image is, and it's way more complicated to have your image inserted for you in your wiki page or text area.
** You have to start scrolling and scrolling there in the elFinder window to look for something... I know my image was called (real example from today) "tiki13_tracker_events_00.png".
** I typed "tiki13_tracker_events" in the search box, and nothing was shown (!).
** I typed "tiki13_tracker" in the search box, and nothing was shown (!).
** I typed "tiki13" in the search box, and dozens of images where shown (!!!).

At this time, my annoyance started to increase quite a lot, as you can image...

We need to make the lifer easier for the end user (and for the *.t.o Tiki contributor)

^ Expected behavior with elFinder:
* Once the file has finished uploading, we expected to have elfinder automagically search for that file name ("tiki13_tracker_events_00.png"), and display the end user JUST the icon/thumbnail of that file just uploaded, so that this human being can easily click on it to have it inserted.
^

Thanks for improving this lovely elFinder interface! :-) {sign user="xavi" datetime="2015-01-26T10:13:55+00:00"}

When I edit and try to save a page when logged in as an administrator, I get the error "A contribution is mandatory" and it will not save. Registered users and all others cannot save edits either. We're only using the wiki feature and the files feature, so this makes it pretty useless if we can't edit it.

This error occurred in the previous version as well, but has carried over to the new version.

This apparently edited a previous report and will not allow me to change the selections. I'm now on 4x and it's a Wiki problem, not a File Gallery problem. I can't seem to submit a new report; it keeps editing an old report. So there's a problem with the Bug Report system.

expose more validation methods for tracker fields: numeric range, for instance (or positive value, etc)

Example:
http://jqueryvalidation.org/range-method/

This is the use case: a Tiki site creates a lot of similar documents (which end up as PDF files) in the form of wiki pages assembled from a combination of included pages and text that is copied from "template" pages and customized. When the pasted section of text is edited for improvement, it would be good to be able to see where that section was copied from in order to improve that page (the base or "template" page) as well.

Maybe this could be done if there was a feature called "CopiedFrom" that, when activated, would print comments before and after the pasted text such as

-+Copied from "Template Page A" start+-
''The copied/pasted content is here.''
-+Copied from "Template Page B" end+-

These comments could be ~np~ ~t c~wiki comments~/t c~ or <!-- HTML comments --> or mPDF {DIV(class="d-print-none")}{DIV} comments ~/np~, depending on the site requirements. I don't know if the comment type needs to be selectable per instance or global at the site.

As this is kind of a rare use case, maybe it could be implemented as a Vue.js widget (just a thought). It would have to have the ability to get the page name or URL where text is selected and copied and print it as indicated where the paste is made.

Spreadsheets can be created directly through wiki SHEET plugin directly within wiki pages. this allows managing big tables visually, as well as having the data ready for producing graphs, etc. (see documentation for tikisheets at doc.tw.o, if needed)

However, when you create a sheet through a call to the SHEET plugin from the wiki page itself, there are 3 issues which need to be fixed:
# you need to know the id you want to assign it to,
# after that, tiki-sheets.php doesn't list it (even if the sheet is really created, and you can import data to it, and show it at the wiki pages, etc.).
# the sheet is not shown with the right css

Even if we have wysiwyg option available, I still think that is worth improving tiki sheets usability to be used directly from wiki pages, once those 3 previous issues are fixed.
---
Updated on Feb. 2, 2011, using trunk (7svn)
# Steps to reproduce the first issue
## Edit a wiki page
## Use the plugin helper to create a new sheet in that page. And since it's a new sheet, it doesn't have a sheetId yet, so that you leave all fields empty in the plugin helper for the pluginsheet
++ this will add this type of code in your wiki page:
++ {CODE()}{sheet}{CODE}
## Save the wiki page
++ you will see an empty sheet shown in place at that wiki page, with the button at the bottom to allow the user to "edit it" (so far, so good)
## Once you click in the edit sheet button, you end up in some url like this one:
++ http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=&parse=edit
++ which produces a WSOD (blank page).
*** In my case, I guess that this url should have been:
+++ http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=2&parse=edit
+++ since I had only one sheet previously created, with sheetId 1, so that the next one should be 2. However, this new url is still producing WSOD for me. (tiki caches cleared, just in case, repeated this step, and same WSOD)

The expected behavior is that the user is the user would be editing a blank new sheet with the url:
http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=2&parse=edit

and when the user saves that sheet, the new sheetId 2 exists, and the user is either sent back to the wiki page where he clicked at the button "edit sheet" (preferable option) or either sent to the corresponding tiki view sheet 2.