Table of contents
- TikiFest Planning (topics/activities)
- Fixing sessions
- Editing a Plugin via plugin helper icon on a translated page looses the translation assigned!
- Tracker plugin, we can’t set the fields order anymore
- Plugin inline editing is saved but modal stays open
- Plugins should refresh content at start of inline editing to avoid overwriting previous changes
- Numeric field 0 value is returned as "No value" in the plugin list
- Tracker plugin, transaction step don't work
- Rebuild index exit page not where it started (BS)
Tracker plugins are not displayed in the plugin help anymore
Fixing and improving GUI for the plugin list
- Intertiki "Never logged" wrongly over user on the userlist (JB)
- Fixing multiple errors on page all over Doc and Dev (JB)
Structure create a child page is not there anymore (BS)
- Fixing Demo/Tiki pending stuff
- Reviewing trunk for regressions (untested commits)
- Features request
- Fixes and opinions
- Pending (ongoing, not yet finished)
- Future TikiFest planning
- HAVE FUN !
Crash course: how to solve "small" bugs and track regressions (phpStorm) - (started)
plain page, no more admin icons, etc
Opinions on suggested features of restricting the number of login devices per user.
I am thinking I could limit the browsers a user can use each month (via cookies?) to 3.
When a registered user connects to xxxxxx.com, we set a cookie in his computer, and we register his computer/browser as "authorised computer for 30 days"
Every time he comes back to xxxxxxx we read his cookie to we check if he is an "authorised computer". If he is already authorised we let him log in, if he is not we check how many "authorised computers" do we have listed from him. If we have less than 3 authorised computers we register his new computer and let him log in. If he already has 3 authorised machines no deny the login.
In case a computer is not used in 30 days we drop it from the list of authorised computers.
Looks good for Tiki19? Needs rethinking? Looks good to me.
According to https://doc.tiki.org/Pretty-Tracker#Syntax_tips we should be able to access and display all fields of a tracker item in the template of TRACKER plugins plus the following:
($f_create): created date ($f_status_input): status input field ($f_status): status (output) ($f_itemId): the item id ($f_lastmodif): last modified date (this will display unix date, for human readable date look below) ($itemoff): the iteration number of each item ($tr_offset): the offset of the item, i.e. this is the nth item of the total number of x items
We should be able to access and display all fields of a tracker in the outgoing mail template.
According to https://doc.tiki.org/PluginTracker we are also missing the following:
$mail_user $mail_trackerId $mail_item_desc $mail_trackerName $mail_machine $mail_machine_raw $server_name $status
See SAML-SSO-Authentication, SAML and SAML
Recently on an initiative of Marc Laporte php-saml by onelogin.com was implemented to Tiki. It should be possible to setup a Tiki as SAML Identity Provider (IdP) and as SAML Service Provider (SP). Getting this to work and documented for the enduser (currently the documentation is barely existing) would allow SingleSignOn (SSO) across various websites, given they are also capable of SAML login/logout respective of using SAML authentication against an IdP. Tiki as IdP brings SingleSignOn to the average SharedHosting customer who cannot afford to install and maintain for example a dedicated LDAP server.
A non-profit organisation runs a Nextcloud, a Tiki website (or another CMS with SAML authentication option) and a Tiki based members wiki/forum/... .
Active members of such an organisation often complain about the necessity of several logins with extra password on each and that they have to login to each subparts of the environment. When passwords are changed on one subpart, the passwords on other subparts are not automatically consistent, respectively not changed accordingly. result might be the use of easy to remember unsecure passwords, the use of same password on several independant accounts or avoiding to use the apps at all.
With SAML SSO the organisation can provide the users the experience of using one complete app/environment where it would not be important where the users start to work, as they are logged in and logged out throughout the whole set of subparts of the webproject. Nextcloud contains WebRTC based Voice/Video and Chat besides file sharing and other collaborative features well adding to Tikis advanced collaboration and publication features.
By adding a dedicated server or Cloudserver (ex: Docker environment) it would be possible to add Libre Office based Collabora Office (version CODE = free open source) to the Nextcloud for online and optionally simultaneous File creation and editing (very similar to Google Docs or Office 365) plus Elasticsearch for advanced fulltextsearch in Tiki (maybe aswell in Nextcloud/Collabora).
The onelogin/php-saml code installed by the Composer based new Tiki feature Packages was evaluated and the SAML partly configured on the IdP side and the SP side with two Tikis. Currently the setup does not work yet and it is not clear, if the implementation is complete or robust. Although it looks like the implementation is complete enough, that it can be made running with the current code with configuring files and control panels only.
Some help by a SAML experienced developer or the coder of the SAML-Tiki implementation would be helpful and appreciated, Torsten Fabricius .