Roundtable Meeting today at 13h UTC & topics

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Roundtable Meeting today at 13h UTC & topics

Xavier de Pedro (Tiki)

Hi, it's "Tiki Roundtable (monthly) Meeting" time again ( open to anyone from the Community = YOU :-)

It seems that the most voted time for today's TRM is 13h UTC (even if just a few people indicated their preference), it the only of the options that I was able to keep today, and I suggested weeks ago a few topics myself to expose and discuss (some of them urgent, imho). Therefore, since I also accepted to be the facilitator (no other volunteers by the time ;-), it's confirmed at 13h UTC, and it wil be recorded (for those of you whou couldn't make it but interested in the news a topitcs scheduled for today).

So far, se the list below (copied from the TRM page to facilitate quickly reading by many more: ):

See you later!



1st hour quick news

  • Shall we remove the Post-it note on asking users if they have already upgraded their sites? 
  • New Profiles in development for Tiki15+: (already in "beta")
    1. "Execute on List" 
      To ease the learning of how to use (and detect bugs in the future) of a few features not covered enough in previous profiles:
    2. "Work_Custom_Pricing"
      • demostrate some enahancements to item link and trackers in general to allow while adding an item to tracker 1, select many linked items from a second tracker, and let a mathematical calculation field perform a formula on some of the fields from the linked items selected from the table inserted on the fly.
      • in addition, implemented a simple way to get prices from a price guide (in tracker 3) but allow you to override them in the item of tracker 1, for invoicing purposes with different end prices depending on type of customer, other agreements, etc.

    3. GeoCMS_Maps
      • Easily demostrate geo location capabilities of Tiki in several features of the CMS: Wiki pages, Tracker items, Blog posts, and articles.
      • Show maps per feature, or everything in an integrated map.
      • Ideally, some filtering capabilities will be included, with plugin Custom Search and eventually other tricks.

    4. Bug_Tracker_15
      • Easily demostrate some of the new features added in the last versions compared to the old bug_tracker profile (tracker inline edition, sortable tables, change field type, clone items, etc.) ...
      • ... as well as the new PluginPivotTable coming along in trunk so far. Ideally to be backported to 16.x and 15.x once 16.0 is out.
    • have a base infraestructure to test the email notification system to tracker fields of type "user selector" once they have been set to get notified of changes to the corresponding tracker items matching the username.
  • Who is planning to attend TikiFestFosdem2017?

Second hour, longer topics

1. profiles.t.o upgrade plan to ease filtering and sorting of profiles? upgrade plan to ease filtering and sorting of profiles? 

  • We would need some way to create a sortable and filterable list of Profiles from the Profiles Wizard in tiki instances (ideally), and at profiles.t.o site, at least. There are way many profiles ready for learning features in the Profiles Wizard and profiles.t.o, and people are not learning from them because they might not know which profiles demostrates how to use feature X or Y, etc.
  • uses Tiki 9.x, which doesn't have Tablesorter. Tiki12 does. Shouldn't we plan some upgrade to Tiki 12.x at least? Any schedule? Any blocker issue preventing that from happening?
    • In addition, profiles.t.o is on ovh server, which runs on and old OS which needs upgrading, and hard disk space needs an increase to prevent irc.t.o log web display issues from happening too frequently (maybe) lately.
    • is currently also in the same ovh server
  • That would allow to make a better filtering and sorting of profiles which are ready for each version, etc.
  • Alternatively we could document on or elsewhere, and reuse with iframe or something.
  • Imho 'Profiles' is was an underestimetated treasure and one of those features making Tiki outstanding above other CMSes. Imho the 'Profiles' community site deservers a similar overhaul as the Themes website and should look responsive and nice same as ''. - at least marketing wise. (thx to the guys bringng 'Profiles' on to the agenda!) 

2. URGENT: Changing spam reduction strategy in

We seemed to have setup the randomstring keyword needed ("Registration page key") in the url for the registration screen to show up in, but this was blocking users from registering since there was a hand made link to "Register" in the tiki homepage that didn't have that keyword string manually setup in that hand-made link.

Conclusion: users that clicked at the link from the Homepage couldn't register. And the link to "register" frmo the login module didn't work either for me the first time I tried but only after I disabled the feature "Registration page key" and re-enabled it again (caching issue? was that recently setup in )

Anybody aware of other places were we did setup custom links to "Register" or tiki-register.php?

2.2. new user admin validation in (intertiki) by a single person

Regardless of the many thanks we need to give to the person that has been taking care of validating new user requests in, we cannot rely in this custom hand-made single-man procedure, since it means a bottleneck and too much pressure and responsability on a single person for such an important entry point of new users, reviewers and developers to the Tiki community.

I did a quick review, and there were plenty of legitimate registration requests to (like the ones reminded on irc and through personal emails days ago to some admins), and dozens of others in the last weeks. Even found some legitimate requests from several months ago (4 months ago, 8 months ago, ...) among dozens of spammer registration attemps. So 
the man-made work was woprking pretty well, but indeed not well enough. And it's not a single-man responmsibility. Therefore, I propose to change this situation to a more automated process of allowing users to register first, and only when proven that they spam, then we can remove + ban ip, etc.

For instance, validation of new user requests can NOT be done in bulk in the user admin UI (not even easily reviewing theuir user tracker records with a single click from there), but removing and banning ip's can be done indeed in bulk from several places (user admin UI, action log UI, etc).


Check out the vibrant tech community on one of the world's most
engaging tech sites,!
TikiWiki-users mailing list
[hidden email]