Category: Community projects

I edited several items in the tracker 24.
But I couldn’t save edit on this item : https://tiki.org/item10362 (They should be some restriction to view this tracker as it is not public)

I tried several times, refreshed several times (MacOSX, Safari and Chrome):
{img fileId="1238" thumb="box"}

I create 2 tracker item that are related.

https://dev.tiki.org/item6746 and https://dev.tiki.org/item6746
When I try to set the relation field none of them appear in my search list not with the start of the title not with the item id.

Something doesn’t work as it should.

I just reviewed Canadas anti-spam legislation & it looks like we're currently not complying with it.

http://fightspam.gc.ca/eic/site/030.nsf/eng/00285.html

# Express consent (rules for implied consent are too difficult to satisfy)
# Name of the Sender
# Address of the Sender.
# A way of getting in touch with the sender. (phone number, domain name, email address) For us, a simple domain name would be ideal.
# Easy unsubscribe mechanism.

I just reviewed an email I received from a user watch at dev.tiki.org. We comply with (maybe) #1. 2-5 we do not comply on.

A lot hinges on if the emails we send out are considered "Commercial Electronic Messages" but we don't appear to fall in the exception list, so I'm guessing that means almost all our messages are considered CES, including watches.

There is implied and also explicit consent. It looks like most of our emails are explicit concent emails, so that makes things easier. However if no specific action was taken to request an email, it falls in "implied consent" and there is a 2-year limitation on this clause. That would be a lot of work to program, so I suggest that we place a line in our Terms and Conditions that states that we may send occasional emails, and require them to agree to these upon registration. This would seem to cover our basis in making a strong case for explicit consent. The onus is upon us to prove that explicit consent has been granted. The empty toggle box concent is mentioned as "acceptable" under these regulations.

Now that we have explicit consent (and can prove it) we need to comply with the required information in an email. For Tiki already has the name and domain name, but perhaps we need a field for the business address in the preferences somewhere.

We also need an "easy unsubscribe mechanism" so if someone creates a "user watch" we need to include a link to an unsubscribe page. Or a page that unsubscribes them. I'm sure we already have this within tiki, we just need to generate the link and include it in user watches, and other emails.

It would also be nice if we had some generic compliance built into Tiki. So the solution taken is not specific to *.tiki.org and everyone else needs to come up with there own solution. More and more legislation is playing a larger role in how business on the net is conducted.

I would love to see a generic feature in Tiki called something like Terms, Conditions & Privacy Policy. Where terms, conditions and privacy policy can be (almost) auto generated based on selected options. This then could be integrated into the user registration form as part of the standard process.

For each new release, part of the info is on doc.tiki.org/Tiki8 and part is in https://tiki.org/ReleaseNotes

Many times, no one creates a ReleaseNote page and it gives a broken link to users.

Let's stop this.

Let's put all links to the doc.tiki.org/Tiki8 and if there are any relevant release notes, they will be added there.

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

toggg fixed the broken Wiki-parsing in Blog/Trackers etc. - basically every feature except Wiki

We now need to cross-check for breakings!!

To get a list of all files to check, use this command:

$ find . -name '*.php' -exec grep -iEH 'parse_data\(' {} \;

[23:29:48] <red_adair> who knows tiki-atom ? it's you amette talking of it, no ?
[23:30:05] <amette> tiki-atom - that's completely unknown to me! :O
[23:30:19] <red_adair> $description = htmlspecialchars($tikilib->parse_data($chg["$descId"]));
[23:30:29] <red_adair> is kinda weird
[23:30:43] <amette> it redirects me to tiki-view_articles.php....
[23:31:52] <mdavey> tiki-atom : mose, march '04
[23:32:57] <mdavey> oh, it is for RSS atom feeds
[23:33:12] <amette> better not kill it then.. ;)
[23:34:20] <mdavey> I think it might be redundant - I think that the RSS library we use supports atom, too, now. Need to do some investigation.

This occured to me, while looking at the homework-perms remove issue...
... could be, that there is still something left... not sure though - reminder!

* make sure all is OK since TRIM was built before ((Composer)) was added to Tiki. Perhaps Jonny fixed some of these?
* Some commands made via TRIM should perhaps use the newer ((doc:Console)) commands? (which is a risk to break older installs. Perhaps use the command depending on the Tiki version?)
* If all this is too complicated, we may have to limit support to 12.x, but that would be a shame since 9.x LTS is still supported

Hi, I just want to get a fresh pre-17 trunk show instance to have a look wether and how the H5P integration proceeds and how to use.
{sign user="Torsten" datetime="2017-03-13T23:15:30+00:00"}

As discussed at the September 2013 webinar, we'll do 5 years starting in Tiki12 and no change to 9 and 6.

We need to describe what support means, and reduce expectation from the externals (we don't control their lifecycle)

Simple: send mail to XYZ or use this tracker

Better:
a page with a list of contacts for each site

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

Often times there are bugs that are never closed even though an actual fix has been applied. There is also the strong times where a fix was done that actually solves a bug that is in the tracker even though the developer might not have known is was there.

It would be great to have a way (maybe using NLP in Tiki 12) to have a dashboard of all the SVN commits, when you click on it, it would give a list of possible related bugs that are still open. This would allow the WishList team to clean up the old bugs and also make it easy for Developers to perform this check when comitting fixes.

clicking on Calendar on next.t.o takes you to the calendar for a split second then a redirect happens and takes you to the info.t.o calendar.

Not sure if this is suppose to be the behavior?

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"}

Tested on https://doc.tiki.org when you click the cog icon in the top bar and then one of the control panel icons in Chrome it does nothing (does not go to the control panel).

The page "comments" on tiki.org returns a 404 not found.

I have looked in the wiki pages, and we do in fact have a comments page, so something must be broken there. Not sure if this is a tiki bug, or bad data or what, but the error message (404) is really not very helpful.

https://tiki.org/comments -- is broken
https://tiki.org/tiki-index.php?page=comments -- works

https://tiki.org/changelog -- is broken
https://tiki.org/tiki-index.php?page=changelog --works

((tw:RestoreHelp))


If this is not ready in time we'll deactivate the feature and put a note to users than when they the should expect some 404 pages and that their help is welcome.

composer.lock needs to updated
* when composer.json is updated
* to get updates on any of our 100+ dependencies

Tiki developers sometimes waste time with this. Let's automate.

It should be ran with the right version of PHP (the lowest supported for that Tiki version)

Also, each branch needs to be run independently (you should't merge the results of one branch in another). So this should be excluded from the script at ((Semi-automatic merging period))

We need a robot SourceForge user name. Ex: tikicibot


One example: (up for discussion):
# Check all changes on composer.json and update immediately composer.lock (because a dev working on something likely wants to see immediate results)
# Update composer.lock every 10 days on supported branches. So we get somewhat frequent updates. Since composer.json is set for semantic versioning, it should not cause regressions.

Also, there is some weirdness where the composer.tiki.org URLs are changed to the external sources like Github.
http://sourceforge.net/p/tikiwiki/code/68089
This automation should keep everything on composer.tiki.org

This should also be done by the release script

I have "Require confirmation of an action if a possible CSRF is detected" set on tiki-admin.php?page=security. When I get the warning "Possible cross-site request forgery (CSRF, or "sea surfing") detected. Operation blocked.", and I click the "Click here to confirm your action" button, the same warning page redisplays instead of refreshing to the page where the admin action was made. This repeats as long as I keep clicking.

But the admin change does get made. If I input the admin page URL or go back in browser history to the admin page, I can see the change did take effect.

This is on my local wamp installation, so I'll need to make a show instance unless other people can reproduce this bug.

Some checks were received at the wrong address, and forwarded to Nelson to be deposited.

Please confirm they have been received and deposited.

Please contact Mike from InMotion Hosting to provide him with any final missing info to finalize our Hosting Partnership

Convene plugin missplaces the counts in columns after the winning choice. See it reproduced in the screenshot below:

{img fileId="1093" thumb="box" width="600"}

In
https://tiki.org/Roundtable+Meeting+2016+09

After the count with the more votes (7, at the time of this writing), and the icon with the checkbox-like icon to indicate that this was the winning choice (Thu 15 Sep 2016 15:00 CEST), there is a button box in orange in the screenshot that should show a calendar icon, and that button allows to send that date to the pre-defined tiki calendar.
https://tiki.org/tiki-calendar_edit_item.php?todate=1473944400&calendarId=7

But no calendar icon is shown, and the count of votes for the next date (column in the table) is shown there instead ("3" instead of the calendar icon), and the next counts are also one column before where they should be.

It seems like for every added user it duplicates the votes entries in the plugin body.

It works when the duplicates are manually deleted from there so presumably the duplication is unnecessary and unwanted.

See:
https://tiki.org/tiki-pagehistory.php?page=Roundtable%20Meeting%202016%2009&compare=1&oldver=23&newver=24

Same thing is happening still with tiki 20.x on t.o. Reproduced these weeks here:
https://tiki.org/201909-TAG-Meeting?latest=1&amp;page_ref_id=1318

I just edited this morning a couple of options in my choices, through the convene UI, and the edition added itself in the background a clone of the plugin body several times {sign user="xavi" datetime="2019-08-28T13:35:45+00:00"}:
https://tiki.org/tiki-pagehistory.php?page=201909+TAG+Meeting&newver=45&oldver=44