Notes:
- QuestionValidator didn't have a :name field but that seems like a mistake
- `_fields` functions can't inherit others because of some Validators
- bto/bcc fields were absent in activities, also seems like a mistake
(Well IIRC we don't or barely support bto/bcc anyway)
* Policies were put under a new module (Pleroma.Web.ActivityPub.MRF.Policy instead of Pleroma.Web.ActivityPub.MRF), but this wasn't changed in the Pleroma.Web.ActivityPub.MRF @mrf_config_descriptions
* I don't have a unit test to prevent similar problems in the future because I don't find a proper way to do it
* The descriptions in the unit tests are defined in the unit tests, so if someone changes module names in the code, the tests wont see it
* The list is generated in Pleroma.Docs.Generator.list_behaviour_implementations, but I can't do a check in the when clause of the function to see if the provided module is a behaviour or not.
Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3509
The original approach to search in GIN indexes is to use
`to_tsvector(text)` in the WHERE clause of the query. According to
postgres docs [pdoc], this method does not make use of the index,
while `to_tsvector(config, text)` does. This commit changed the
query to use the two-argument `to_tsvector()`.
[pdoc]: https://www.postgresql.org/docs/12/textsearch-tables.html
To obtain the search config in use, we make a query to the db first.
The `::regconfig::oid` hack is needed because Postgrex does not support
regconfig type directly [postgrexbug]. I use the conversion from and to
`oid` instead of `text` because I tested in the actual DB and querying
using the conversion via `text` is slow just as the one-argument
`to_tsvector()` variant.
[postgrexbug]: https://github.com/elixir-ecto/postgrex/issues/502
Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3519
Closes: https://git.pleroma.social/pleroma/pleroma/-/issues/2758
* To see what front ends are installed, it ls static/frontends. When this folder doesn't exists yet, it will return an empty array.
* Installing still works since the folder is created during installation already
Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3510
The original approach to search in GIN indexes is to use
`to_tsvector(text)` in the WHERE clause of the query. According to
postgres docs [pdoc], this method does not make use of the index,
while `to_tsvector(config, text)` does. This commit changed the
query to use the two-argument `to_tsvector()`.
[pdoc]: https://www.postgresql.org/docs/12/textsearch-tables.html
To obtain the search config in use, we make a query to the db first.
The `::regconfig::oid` hack is needed because Postgrex does not support
regconfig type directly [postgrexbug]. I use the conversion from and to
`oid` instead of `text` because I tested in the actual DB and querying
using the conversion via `text` is slow just as the one-argument
`to_tsvector()` variant.
[postgrexbug]: https://github.com/elixir-ecto/postgrex/issues/502
BUG: https://git.pleroma.social/pleroma/pleroma/-/issues/2758
* To see what front ends are installed, it ls static/frontends. When this folder doesn't exists yet, it will return an empty array.
* Installing still works since the folder is created during installation already
* Policies were put under a new module (Pleroma.Web.ActivityPub.MRF.Policy instead of Pleroma.Web.ActivityPub.MRF), but this wasn't changed in the Pleroma.Web.ActivityPub.MRF @mrf_config_descriptions
* I don't have a unit test to prevent similar problems in the future because I don't find a proper way to do it
* The descriptions in the unit tests are defined in the unit tests, so if someone changes module names in the code, the tests wont see it
* The list is generated in Pleroma.Docs.Generator.list_behaviour_implementations, but I can't do a check in the when clause of the function to see if the provided module is a behaviour or not.
* I also added for keywordpolicy as well now. It was done in the admin-fe, but is better to be done here
* I also added comments to explain why we did the _info keys (backwards compatibility)
Added a new field in the nodeinfo called quarantined_instances_info
This holds an object like `"quarantined_instances_info":{"quarantined_instances":{"quar.inst":{"reason":"whatever reason"}}}}`
It's easiest (and imo most proper) to use tuples {"instance, "reason"} in BE,
but for FE maps like %{"instance": "instance", "reason", "reason"} are better.
I changed it so that node_info returns maps now for simple_policy and quarantined instances.
