• Extensions

  • FoF Terms, ask your users to accept TOS and Privacy Policy

Terms by FriendsOfFlarum

MIT license Latest Stable Version Total Downloads

Extiverse

This extension allows you to define a list of terms the user must agree to before using the forum.

It was made with the new General Data Protection Regulation in mind but please consult with your legal team to see whether it fits your requirements.

Compatibility

This extension might not be compatible with other extensions that make change to the sign up modal as well. If an extension is not listed below, please try it on a test forum first and let us know if it works.

Works with:

Does not work with:

Installation

composer require fof/terms

Updating

composer require fof/terms
php flarum migrate
php flarum cache:clear

Updating from Flagrow

This extension replaces Flagrow Terms.

To upgrade from the old extension to the new one:

  • Backup your data! You should backup the database. You can also download Terms' data as JSON, see documentation below.

  • Disable the Terms extension in the admin panel.

  • Run:

composer require fof/terms

Composer should let you know that flagrow/terms has been automatically removed.

  • Enable the new extension in the admin panel.

  • Your existing data will be migrated to FoF Terms automatically.

Configuration

You can define a list of "policies" the users must agree to. A policy has a name and url.

You can define an "update message" that will be shown to users who have not yet agreed to the latest version of the policy or not agreed to the policy at all (this includes users registered before the policy extension was enabled).

You can define an "updated at" time that will ask all users who accepted prior to that date to accept again.

If users don't accept the terms, they can't register. Additionally, if they already have an account, they can login but their account is locked until they accept the latest version of the terms (similar to how the suspend extension blocks users).

You can customize who can skip the modal without accepting the new terms immediately via the permissions tab (by default admins only). You might want to give this permission to bot accounts for example as they will also be blocked from the API if there's a terms update.

Admins can see the date at which a user accepted the terms by going to their profile page and selecting the terms button in the dropdown menu. You can customize who can see those dates in the permissions.

Data Export

In case you want to export the data (for your GDPR logs for example), a JSON and CSV export is available.

The link can be found in the Policy edit form of the admin panel.

If you want to automate the export, the available options are documented on the wiki.

Links

An extension by FriendsOfFlarum

    jordanjay29 for sure.I install the recaptcha ext,The register page under password input box,There should have a reCAPTCHA,But when I after install flagrow/term,The reCAPTCHA has been replaced by THIS ext the optional legal text box.
    This make my user can verifyed the reCAPTCHA to register account.

    This happed on OFFICAL FLARUM too.

        To everybody having a look at this extension: it has not been tested for compatibility with other third-party extensions.

        Given how little extensibility Flarum offers in modals (and here in the signup modal) it's quite possible that two extensions modifying it will collide and break.

        Please report any incompatibility in the GitHub issues. Don't forger the output of php flarum info or composer show so we know the exact versions installed. You can disable other extensions to pinpoint which one isn't compatible. If the other extension if pretty popular or the fix is simple I'll try to get them working together. Otherwise I'll build a list in the README to indicate incompatibilities.

        Also a heads up: if there's any issue with a Flarum fork, Flagrow most likely won't fix the issue. All our new extensions are currently made and tested for the official beta 7 and 7.1. Thanks for understanding ?

        EDIT: Ghost_chu can you open an issue on GitHub with the link to the recaptcha extension concerned ?

          First bugfix release already. 0.1.1 fixes an issue if you have an older version of nesbot/carbon installed.

          Get the fix with composer update flagrow/terms.

          composer update nesbot/carbon would also fix the issue.

          5 days later

          Just released 0.1.2 which adds Spanish translation.

          Update with

          composer update flagrow/terms
php flarum cache:clear

          @clarkwinkelmann

          I have several problems installing this extension.

          First of all: the tables created by this extension were of type InnoDB whereas all the other tables of Flarum are MyISAM. Is this supposed to be that way? Additionally I got errors I unfortunately didn't save and don't remember anymore.

          Then I changed the default storage engine to MyISAM but with limited success. Only one of the tables was created, so I created the other table myself according to the instructions in the migrations, but it seems I made mistakes there, as I could activate the extension but adding a policy resulted in a strange error:

          Column not found: 1054 Unknown column 'updated_at' in 'field list'' in ...

          When I renamed terms_updated_at to updated_at, I got the error:

          Column not found: 1054 Unknown column 'term_updated_at' in 'field list'' in ...

          So I decided to go back to start: removed the extension via ssh, removed the tables flagrow_terms_policies and flagrow_terms_policy_user, removed the columns flagrow-terms.hide-updated-at and flagrow-terms.signup-legal-text in the settings table (only those had been added during my previous trials), and changed the default storage engine back to InnoDB.

          But now my database seems to refuse to create the tables flagrow_terms_policies and flagrow_terms_policy_user when I reinstall your extension. Accordingly, the admin panel throws an error:

          SQLSTATE[42S02]: Base table or view not found: 1146 Table 'flarum.flagrow_terms_policies' doesn't exist (SQL: select `flagrow_terms_policies`.*, `flagrow_terms_policy_user`.`user_id` as `pivot_user_id`, `flagrow_terms_policy_user`.`policy_id` as `pivot_policy_id`, `flagrow_terms_policy_user`.`accepted_at` as `pivot_accepted_at` from `flagrow_terms_policies` inner join `flagrow_terms_policy_user` on `flagrow_terms_policies`.`id` = `flagrow_terms_policy_user`.`policy_id` where `flagrow_terms_policy_user`.`user_id` = 1)

          This happens even before I have the chance to activate the extension, so I assume that the migration should take place during ssh composer require flagrow/termsalready. But there is no error message:

          composer require flagrow/terms
Using version ^0.1.2 for flagrow/terms
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing flagrow/terms (0.1.2): Loading from cache
Package http-interop/http-middleware is abandoned, you should avoid using it. Use http-interop/http-server-middleware instead.
Writing lock file
Generating autoload files

          In the database the tables flagrow_terms_policies and flagrow_terms_policy_user indeed don't exist after installing terms.

          Do you have any idea?

            Pollux inside the migrations table delete any entries related to the extension, otherwise the migrations won't re-run.

                luceos This didn't help.

                Reinstalling terms doesn't perform any changes to the database anymore. It doesn't create any of the new tables nor does it create new entries in the migrations or settings table..

                    Pollux re-installing does not run migrations, enabling does. So you would have to re-enable it if you uninstalled it when enabled after removing the migrations entries and tables related to the extension (does this even make sense ? )

                        luceos does this even make sense ?

                        Halfway ?

                        But I'm one step further. My problem was, that I could not access the Admin panel because of the error described above (Table 'flarum.flagrow_terms_policies' doesn't exist). I therefore assumed, that the migration took place during installation and not after enabling it.

                        So how could the Admin panel complain if the extension was a fresh install?

                        The answer: settings.extensions_enabled still contained your extension because obviously I deinstalled it while still enabled. So after re-installing it it was automatically viewed as enabled without running the migration.

                        So, now I have terms installed and the Admin panel doesn't crash immediately anymore. Now I try to enable the extension:

                        exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint' in /path/to/flarum/vendor/illuminate/database/Connection.php:390\nStack trace:\n#0 /path/to/flarum/vendor/illuminate/database/Connection.php(390): PDOStatement->execute(Array)\n#1 /path/to/flarum/vendor/illuminate/database/Connection.php(655): Illuminate\\Database\\Connection->Illuminate\\Database\\{closure}(Object(Illuminate\\Database\\MySqlConnection), 'alter table `fl...', Array) ...

                        Like before, flagrow_terms_policies and flagrow_terms_policy_user are created as InnoDB tables. I don't know whether that's the reason why the foreign key constraint can't be added.

                        Shall I try the path of changing the default storage engine to MyISAM again?

                          I just queried my database: SHOW ENGINE INNODB STATUS

                          The result:

                          ------------------------
LATEST FOREIGN KEY ERROR
------------------------
2018-05-09 13:05:35 0x7000044e1000 Error in foreign key constraint of table flarum/#sql-11ba_5c:
foreign key (`user_id`) references `users` (`id`) on delete cascade:
Cannot resolve table name close to:
(`id`) on delete cascade

                          Does that help?

                          Edit: As I understand the engine should be the same in both tables. But users is MyISAM and flagrow_terms_policy_user is InnoDB. I guess that's causing the error.

                            Pollux once you deleted the tables manually, you should also have deleted the foreign key constraints added by the migrations. Now that you didn't the migrations fail. You will have to remove the foreign key constraints from your database as well before trying to re-enable the extension.

                            This is one of the reasons why doing these things manually often is a bad idea ?

                                luceos This is one of the reasons why doing these things manually often is a bad idea ?

                                That's what I'm learning right now. ? But that's OK for me, I like learning. ?

                                luceos once you deleted the tables manually, you should also have deleted the foreign key constraints added by the migrations.

                                So how do I delete the foreign key constraints in MySQL? The only hack I found was making a copy of the users table without constraints and replace users with that otherwise identical copy.

                                But this didn't solve my problem. I still get the General error: 1215 Cannot add foreign key constraint

                                Are you sure, that the different storage engines aren't a problem? Or should I try to change the default storage engine to MyISAM? What storage engines are supposed to be used in the users table and in those of your extension?

                                      Pollux You could of also dropped the column VIA ALTER TABLE statement.

                                      ALTER TABLE "table_name"
DROP "column_name";

                                      Given that the column is not part of core (which it looks to be).

                                      @luceos any particular reason why ->onDelete('cascade');is used in up portion of the migration and not down?

                                          Ralkage onDelete('cascade') is a Laravel method that simply tells MySQL to delete related records whenever the foreign record is deleted. The down method should have deleted the foreign key constraint, which is possible using dropForeign.