csvalpha / amber-api Goto Github PK

Currently a collection is put in SEPA file. It would be useful to automatically split in batches, as SEPA only supports a maximum of 5000 euros

Currently we return the base64 of the OTP activation QR code. However, the UI does not allow to render this since this is not according to our CSP. We should fix this.

A possible solution will be to return the rendered png instead of the base64 data of the image

Proposal

1: Automatically really destroy deleted emails
2: Automatically really destroy ignored (old) emails

Why

Mailgun only holds emails for 3 days, after that, the emails get destroyed. The only emails that are not automatically forwarded in our email system are emails to an alias for a (semi-)closed mail alias.

When a StoredMail is not moderated within 3 days, it expires and should not live in our database anymore.

When a StoredMail is accepted or rejected, it is soft-deleted.

The purpose of soft-deletion is recovery and debugging issues with this feature critical to our association. However, there are privacy-reasons for not keeping them forever, and after 3 days they are not relevant anymore anyway.

How

My suggestion is to execute a CleanupExpiredStoredMailsJob every day, that:

1. really_destroy!s 2-week-old soft-deleted emails
2. destroy 4 days old ignored emails

That way, we reduce the amount of irrelevant (for us) but potential privacy-compromising information in our database, but still allow a grace-period for debugging issues.

I estimate that a 2-week window before really destroying emails is enough for a member to 1) spot a potential email loss and 2) tell us about it – whereas 1 week will be too short.

Extra

I think we also need to inform a user if an email expired. The moderators would get an email like "The email with subject #{something} has expired".

Copied from alpha-banana-api(dutch):

Doel

Het verbeteren van het sturen van mails naar aanwezigen van een activiteit.

Huidige situatie

Momenteel is het mogelijk om via een knop een mail te sturen naar alle aanwezigen bij een activiteit. Deze functie is handig maar wordt weining gebruikt omdat hij slecht vindbaar is en als onbetrouwbaar wordt ervaren.

Voorstel

Elke activiteit krijgt een uniek automatisch gegenereerde mail-alias welke semi-gemodereerd is waarmee alleen de organiserende commissie alle ingeschrevenen kan mailen.

Currently JSONAPI headers are disabled as it does not work in rspec and there is no docuementation to get it working

REF:https://github.com/csvalpha/alpha-banana-api/blob/staging/app/controllers/application_controller.rb#L11

copied from alpha-banana-api (dutch):

Voor PR #594 was er een probleem met de StaticPage find_by_key method in de resource. Lokaal ging dit echter gewoon goed, maar in productie niet. In die PR is het probleem opgelost maar is er geen test voor geschreven. Er moet nog even goed uitgezocht worden waar het door kwam en hoe we dit in de toekomst kunnen voorkomen.

Currently the user fields are a bit of a mess. It is not clear when they are required and to which 'category' for the frontend they belong. I hope this issue makes this clear and makes it possible to implement this.

The main difference with the current implementation is that some fields become required as soon as the user is activated.

Another option to fix this issue is to give everything a default and add a boolean which keeps track if the user should see the 'privacy check popup'.

Currently if the improvmx mail send job fails somewhere it will restart afterwards and will reprocess everything that has already been done. This should be fixed.

Copied conversation from alpha-banana-api (dutch):
@cmitz Webpush

Ik ben bezig met het mogelijk maken van push notificaties mbv de Webpush API. Echter komt daar ook bij kijken dat we op de server gaan bijhouden welke notificaties een gebruiker wil hebben. Ik wil graag discussiëren hoe we deze settings gaan bijhouden.
Voorstel

Ik denk dat een gebruiker zich moet aanmelden voor notificaties. Per email of webpush, ik zou een verschillend type notificatie verwachten bij een nieuw QP bericht dan bij een nieuw bericht op een forum topic dat ik volg. Met het onderstaande model kan je de volgende notificaties maken:

Bij een nieuw QP berichtje
Bij een nieuw forumtopic
Bij een nieuwe post in een topic dat je volgt
Bij nieuwe fotoalbums
etc

Een persisted model: Subscription
Velden:

user
content_type (QuickpostMessage|Forum::Thread|Article|PhotoAlbum|Photo )
content_id (optional, bij nil op alle van dit type)
notification_type (:email|:webpush)

Het nadeel hiervan is het polymorphisme. Je wilt een User koppelen met een "unit" op de website, maar omdat het meerdere types kunnen zijn (en een notificatie wel vrijwel altijd hetzelfde is) denk ik dat dit het mooiste is.

Ik wil hier graag ook een reactie van @tcoenraad op :-)
In de UI

Bij bijvoorbeeld een forumthread of fotoalbum verwacht ik een knopje in vinkje "Thread volgen". Volg algemenere notificaties zoals QuickPost, nieuwe artikelen of threads en andere dingen verwacht ik deze opties aan te kunnen zetten op de settings pagina.

Daar verwacht ik ook een stukje waar je alle bestaande subscriptions kan inzien/uitzetten.

@Matthijsy Ik vind het een goed idee. Ik zou echter het mail type niet doen, verwacht niet dat dit echt gebruikt gaat worden. Wat ik in de ui nog zou toevoegen is een notificatiecentrum (zoals Facebook ook heeft) zodat je daar alle notificaties ook te zien krijgt

@cmitz Een notificatiecentrum klinkt goed, alleen moeten we dan naast subscriptions ook notifications gaan bijhouden. Ik kwam met het type mail, omdat ik het zelf erg prettig vind om bij een nieuw forumbericht een mailtje te krijgen. Net zoals ik dat eigenlijk ook met github heb. Mail is wat persistenter dan een pushnotificatie, en zoveel nieuwe content is er niet op de alpha website - helaas

@Dennis17 Oeh. Cool.
Willen we ook zowel mail als webpush tegelijk ondersteunen? Dan moeten het aparte velden worden.

Het subscriptionmodel lijkt met goed. Misschien is het nog wel te onduidelijk. Als je op Forum::Thread met id 218 geabbonneerd bent, wat houdt dat dan in? Krijg je alleen notificaties van nieuwe posts in die thread, of ook als de thread gewijzigd wordt? Terwijl Forum::Thread met id nil je abboneert op nieuwe forum threads? of is dat Forum?

Misschien moet er nog een soort actie bij. Bijvoorbeeld Forum::Thread met id 218 en event new_post is een subscription op nieuwe posts binnen thread 218.

Als we notificaties willen bijhouden, moet er ook een Notification model komen. Wordt dit dan een algemeen model, of komt er voor elke soort notificatie een aparte subclass (ik ben voor het eerste)

@cmitz
Willen we ook zowel mail als webpush tegelijk ondersteunen? Dan moeten het aparte velden worden.

Hoeft niet per se. Dan maak je gewoon twee subscriptions aan.

Als je op Forum::Thread met id 218 geabbonneerd bent, wat houdt dat dan in?

Ik denk dat we dat per type content apart moeten bekijken. Niet alles hoeft configureerbaar voor de gebruiker, ik denk dat een goed doordachte default genoeg is. Met een actie erbij specificeer je al wel vrij veel in het subscription model, terwijl die logica juist bij het content type zelf zou kunnen blijven.

Is het bijhouden (een persisted Notification model) echt nodig?

@Matthijsy Aangezien de notificaties zoals eerst uitgewerkt niet werkte wil ik een (beter voorbedachte) nieuwe poging doen. Ik denk aan het volgende:

Een gebruiker kan zich inschrijven voor notificaties van een bepaald object. Denk hierbij bijvoorbeeld aan alle nieuwe QP berichten, een forum thread (ofterwijl alle nieuwe posts binnen die thread), of bijvoorbeeld een wijziging van een gebruiker. Let hierbij op dat een gebruiker zich dus kan inschrijven voor nieuwe objecten maar ook voor het wijzigen of verwijderen van objecten. Dit subscription model heeft de volgende velden (ongeveer zoals Casper voorstelde):
Velden:
    user
    model (QuickpostMessage|Forum::Thread|Article|PhotoAlbum|Photo )
    model_id (optional, bij nil op alle van dit type)
    model_action (Create, Update, Destroy)
    type (email xor ui)

Voor elke actie die er op een model wordt uitgevoerd (Create, Update, Destroy) wordt er voor de ingeschreven leden een Notification aangemaakt. Dit zorgt mogelijk voor wat load op de server maar door dit alleen voor de ingeschreven leden te doen zal dit beperkt blijven. Dit model ziet er dan als volgt uit:
    user
    content (het model waar wat mee gebeurd is)
    model_action (Create, Update, Destroy)
    did_read (boolean)

Dit notificatie object kan vervolgens gebruikt worden om de bolletjes in de UI te weergeven. Bijvoorbeeld het laten zien dat er een nieuwe activiteit is aangemaakt door een rood bolletje met een 1 erin bij activiteiten in het menu te zetten. Lukas had hier volgens mij al ideën voor.

Ik ben benieuwd wat iedereen van dit idee vindt. Het is een beetje hetzelfde als de vorige keer maar met de uitzondering dat je je er nu specifiek op moet subscriben

Since doorkeeper 5.1 it is possible to hash the tokens in the database, instead of storing them in plaintext. We should enable this: https://doorkeeper.gitbook.io/guides/security/token-and-application-secrets

Then mail moderation mail is always send. This is probably due to the fact that we do not retrieve the object from the database but from the stored one in Redis.

It could probably be fixed by giving the StoredMail id to the job (instead of the full object) and the at the begin of the job retrieving the object from the db

ref: https://github.com/csvalpha/amber-api/blob/staging/app/jobs/mail_moderation_reminder_job.rb#L5

Some people seem to struggle a bit with the use of CSV files, since Excel can't handle these very well. It would be nice to support other spreadsheet formats when e.g. importing members that Excel can handle a bit better, such as xlsx or ods.

Oudleden should be able to see photo albums of the period that they were member.

To include some of their registration's preceding activities (for example activities during Kick-In) and some possible activities after their registration end, it would be nice to include photo albums of for example 1 year before their registration until 1 year after their registration's end.

Copied from alpha-banana-api (dutch):
@Matthijsy: Op dit moment zijn de adresgegevens van een gebruiker verplicht. Als we straks echter gebruikers gaan toevoegen die er alleen in staan voor het afhandelen van mail (zoals in de MISC lijst) wil je dat niet moeten invoeren.

Code ref: https://github.com/csvalpha/alpha-banana-api/blob/staging/app/models/user.rb#L30

@tcoenraad: Misschien moet dit worden opgesplitst worden in 2 typen users:

full-fledged (user + persoon)
light (user)

Dit is namelijk een direct gevolg van die samensmelting toen. Ik kan me echter voorstellen dat we dit onderscheid 'gewoon' willen maken. Wat voor nu ook kan natuurlijk is dat je een fake adres invult, maar dat is evenmin wenselijk.

@Matthijsy: Dat is inderdaad een optie. Maar de vraag is denk ik ook waarom we een adres bij een gebruiker/persoon zouden willen afdwingen

@cmitz Zouden we misschien een type lidmaatschap moeten introduceren bij Users? Dan kun je aan de hand daarvan validaties strenger maken.

We sturen sowieso wel eens post naar leden, waaronder het constitutiekaartje. Ik weet niet of dat verplicht is, maar we houden het in ieder geval bij met een doel: het ±3 keer per jaar sturen van post

@tcoenraad Misschien moeten we ook even de noodzaak opzoeken van het bijhouden van het adres wink Als iemand geen Digtus wil of een kaartje en er is verder geen noodzaak, moet dat denk ik ook kunnen. Maar als je leden moet kunnen identificeren aan óók het adres zou dat niet zo zijn.

Sometimes the spec of the mail cleanup job fails

1) CleanupExpiredStoredMailsJob#perform when with both deleted emails and expired emails is expected to have received inform_slack(2, 1) 1 time
--
 expected: (2, 1)
 got: (1, 1)

Copied conversation from alpha-banana-api:
@cmitz No description provided.
@Dennis17 @cmitz Kan deze issue specifieker? Gaat dit alleen over validatie of over het versturen van een verificatiemail met een link?
@cmitz Ja jack_o_lantern
@cmitz Het gaat over het bevestigen van een adreswijziging
@Matthijsy Ik stel het volgende voor,

Een 'unverified_email' veld toevoegen waar we een adres tijdelijk in opslaan. Dan een mail sturen om de mail te kunnen verifieren. Deze bevat dan een link met de activation_secret er in om het mailadres te kunnen accepteren.

Currently we have some hardcoded mailadresses (like ict, mailbeheer, no-reply) in our code. Would be good to extract this to the configurations

How to reproduce

Do a request to https://csvalpha.nl/api/v1/daily_verses

Expected behaviour

Get back the daily verse

Current behaviour

404 error

The endpoint right now is https://csvalpha.nl/api/v1/daily_verse but the UI does a request to https://csvalpha.nl/api/v1/daily_verses, which is probably a more logical and consistent endpoint.

How to reproduce

1. go to activities/{id}/form

Expected behaviour

It works

Current behaviour

It does not work. All relationships endpoints from a non-namespaced resource to a namespaces resource broke. This is not a problem for the ui, but it is nice to have it solved.

How to reproduce

1. Send a email with a picture to a moderated address ([email protected] for example)

Expected behaviour

The email should appear on the moderation page on the UI

Current behaviour

The email doesn't reach the moderation page and is lost somewhere

How to reproduce

1. Upload a debit collection spreadsheet which has currency formatting and cells which have a value of €0,-.

Expected behaviour

Spreadsheet is parsed and cells with €0,- are ignored.

Current behaviour

Amounts of €0,- are formatted as "€ -", which fails to parse, so the upload fails

It would be nice if we could add birthdays of members to the ical calendar

I would like to have the option to, when moderating emails, let an email through at a specific time. Because I am often forgetting to let an email through at a later time.

How to reproduce

1. Images in a article and forum should be uploaded at an external image host

Expected behaviour

You can upload an image

Current behaviour

Has to be uploaded on an external image host

Currently we have a limit of 200 SMTP emails per day. For the moderated emails we use the SMTP function, and thus we cannot send too many emails. We should disallow accepting too many multiple moderated mails per day.

Possible solution would be storing if a moderated mail was already send this day. We could store this in Redis and let it automatically expire at 00:00. Then if a mail is accepted we should deny this with a clear error message that there is already accepted a mail this day and that the limit is reached.

If someone has another implementation approach that would work just let it know. Also if you disagree with this.

Currently we return all the users in the /users endpoint. However, I think we should not respond the archived users, unless there is explicit asked for it. This will prevent them from poping up on the website.

Copied from alpha-banana-api:
Hoe te reproduceren

Momenteel laat de webstek wel zien dat je een forumthread al gelezen hebt, maar dit wordt per browser opgeslagen. Gebruik je dus meerdere computers of naast je laptop ook je telefoon, dan wordt niet op elk apparaat goed getoond dat je een thread al gelezen hebt.
Verwacht gedrag

Ik zou verwachten dat op alle devices ik kan zien welke threads nieuwe reacties hebben die ik nog niet heb gelezen.

De enige optie hiervoor is volgens mij om dit in de API op te slaan. Dit kan op twee manieren:

Automatisch, als je de laatse posts van een thread ophaald wordt die thread automatisch al gelezen gemarkeerd voor jou.
Als aparte resource. De UI moet dan zelf tegen de API zeggen dat een thread gelezen is. Dit is meer werk, maar geeft ook de optie om handmatig threads als gelezen te markeren, of weer als ongelezen te markeren.

How to reproduce

delete a user, for example via amber-ui

Expected behaviour

User is deleted and a 200 OK is returned

Current behaviour

The delete operation succeeds, but returns a 404

How to reproduce

1. Create a photo album
2. Set the activity date

Expected behaviour

The selected date of the album is shown in the photo album overview

Current behaviour

The date before the selected date is shown

Copied from alpha-banana-api (dutch):

Het is weer eens tijd voor een nieuw epic, dus hierbij. Het lijkt me tof om een nextcloud integratie te maken aangezien we dan een groot centraal archief kunnen bouwen en dingen ook meer GDPR proof kunnen maken. Dit issue is bedoeld om te bepalen of het nuttig is om het op te zetten en om een design te maken voordat we het gaan implementeren. Ik heb geprobeerd alles met MoSCoW te labelen.

##Functioneel
Ik denk aan de volgende functionele requirements:

1. Single Sign on (should) of op z'n minst inlog met dezelfde gegevens (must)
2. Automatische groepen synchronisatie (must) (bij inlog dan wel via een sync systeem)
3. Automatisch toegang tot mappen van oud-commissies/bestuur (should) en het kunnen maken/hebben van jaar specifieke map van commissie/bestuur
4. Alleen read toegang tot mappen van oud-commissies/bestuur (could)
5. Goede desktop/mobile app (should)
6. Geen tot weinig administratief werk voor het bestuur

Ik denk dat de meeste van deze punten goed uit te werken is. Als we punt 1 en 2 uitvoeren komt punt 3 er als het goed is vanzelf bij via de werkwijze van nextcloud. Punt 4 weet ik niet hoe haalbaar het is maar zou opzich wel tof zijn. Punt 5 zouden we even moeten checken maar als het goed is heeft nextcloud prima ondersteuningen. Punt 6 volgt uit de voorgaande punten, behalve als ik nog wat over het hoofd heb gezien ;)

Implementatie

Ik denk dat kwa implementatie het lastigste de SSO wordt. We ondersteunen dit al wel maar moeten dit nog verder uitbreiden. Ik stel daarom ook de volgende wijzigingen voor.

###ApplicationPermissions (should)
Ik denk dat we application permissions moeten implementeren zodat we niet elke keer als een applicatie meer toegang nodig heeft we hiervoor in de code hoeven te duiken. Ik denk hierbij aan een model wat gekoppeld is aan een Doorkeeper::Application en wat een name heeft in de vorm model.attribute. Ik heb hier specifiek gekozen voor attribute aangezien een applicatie vaak maar zeer specifiek toegang nodig heeft en (tot nu toe) nog nooit iets anders dan read nodig heeft.

###Update van toesteming pagina (UI)(must)
We moeten de UI pagina updaten zodat hij zegt voor welke specifieke applicatie je toestemming geeft. Daarbij kunnen we dan ook de ApplicationPermissions laten zien zodat de gebruiker direct weet welke gegevens hij deelt.

ApplicationGrants (could)

Als we vervolgens ook een ApplicationsGrants model maken dan kunnen we bijhouden wie er al een keer heeft ingelogd en hoefen die mensen dus geen toestemming meer te geven.
/users/me/nextcloud endpoint maken (must)

De sociallogin app die ik gebruikte om de sso in nextcloud te hangen verwacht net een ander dataformat dan dat onze api geeft. Daarom moeten we een specifiek nextcloud endpoint maken

Group sync maken (must)

De sociallogin plugin die ik gebruikte ondersteund geen group sync. Ik denk dat we het beste een Nextcloud plugin kunnen maken (dat gaat helaas wel php zijn) die dit ondersteund. Dit zou een lostaande app kunnen zijn maar ik denk dat het wel toffer is om het te implementeren binnen de social login app. Wat voor de community betekenen is altijd tof!

Ik denk dat dit ongeveer is wat er nodig is. Natuurlijk moeten we niet vergeten om eerst te kijken of we het uberhaupt willen, dus het lijkt me goed eerst een discussie te hebben voordat we dingen gaan bouwen. Daarbij maken bovenstaande aanpassingen onze oauth2 ook completer waardoor we in de toekomst ook meer SSO of andere oauth applicaties kunnen gaan ondersteunen. Ik hoor graag wat jullie ideen zijn en of ik nog functionele dan wel technische dingen heb gemist.

How to reproduce

1. Go signied in to https://csvalpha.nl/photo-albums/44/photos/2325
2. Go signed out to https://csvalpha.nl/photo-albums/44/photos/2325

The same happens for public articles

Expected behaviour

Both should show the same comments

Current behaviour

Server sends a 401 unauthorized on the photocomment
Server sends a 401 unauthorized on the 'related' users at public article comments

How to reproduce

Upload a photo with the copyright (©) symbol in the Copyright Notice EXIF data field to an album.

Expected behaviour

The photo is uploaded and a green checkmark is shown

Current behaviour

The photo is uploaded, but a 500 error is shown and an Encoding::UndefinedConversionError is thrown

Copied from alpha-banana-api (dutch):
Het zou handig zijn als je een artikel (tijdelijk) verder omhoog kan zetten. Dit zouden we kunnen doen met een prioriteits flag. We zouden 2 fields kunnen toevoegen: priority en priority_untill. Dan zouden we een sort kunnen maken die het artikel met de hoogste priority die nog valid is (current_time < priority_untill) bovenaan zet.

@Matthijsy: Update van de vergadering van 26-03. Het idee is om 1 artikel te kunnen pinnen. Het idee is dan om een pinned_untill veld toe te voegen. Maar 1 artikel mag dan tegelijk gepinned zijn.

How to reproduce

1. Create a forum post

Expected behaviour

It is created

Current behaviour

You get a 422, without a clear error message

How to reproduce

1. Go to the photo album index page
2. Go to the second and third page
3. You see the 'gala' albums, however album 353 and 351 are missing

Expected behaviour

You can find them by clicking through the pages

Current behaviour

You can only find the using the search function

The search function does not allow for search functionality such as searching for "<firstname> <lastname>".
The functionality for this should be examined and preferably redesigned to include the option for searching a combination of these two columns. If possible and useful, it could be nice to provide some abstraction for the selection of columns, so that this functionality is also available in other use cases.

If you send an email to enrolled people of an activity, newlines are not shown in the mail:

We would like to migrate our mailsystem to Improvmx, this is a forwarding service for mail that works good.

This are the steps that I would like to follow

• Implement synchronization from Amber to Improvmx (#157)
• Get permission from the board to spend 90 dollars a year
• Get the 'verwerkersovereenkomst' from Improvmx
• Update the privacy statement and inform the members (in progress)
• Implement 'moderated' lists
• Determine what to do with 'semi-moderated' lists (will be open lists for now)
• Implement SMTP (optional, can also be done manual)
• Go Live

Would like what you all think about this

How to reproduce

1. if logged in to Nextcloud, log out.
2. Log in to Nextcloud.

Expected behaviour

Access should be provided to the Nextcloud environment.

Current behaviour

An error page shows, as can be seen in the screenshot. Reportedly, this same error also affects the login to S.O.F.I.A.

How to reproduce

1. try to remove a profile picture

Expected behaviour

Should be deleted

Current behaviour

Not possible

The current board has renamed jaargroepen to kiemgroepen and would like this to be changed on the website. Furthermore, a category for curiositas/curiositates should be added.

How to reproduce

1. Run Time.zone.now on production, or check the Ical data

Expected behaviour

It is in the current timezone

Current behaviour

It is still in the summer time. Could probably be fixed by setting the timezone in the dockerfile

How to reproduce

1. Create a member
2. An error occurs that the picture_publication_prefrerence is missing

Expected behaviour

1. A member should be created

Current behaviour

1. The user cannot be created

See slack for a screenshot

Copied from alpha-banana-api (dutch):

@cmitz Later even aanvullen, nu op startweekend
@tcoenraad Dat is een vrij logische feature om te hebben. Als we naar een zelfafrekend systeem toe willen ook noodzakelijk. Omdat dit iets is wat je niet zelf initieert is het wel belangrijk om de gebruiker (per mail?) te informeren hierover.
@cmitz Twan oppert op de vergadering van 19 februari:

Als het mogelijk is dat een bestuurder ineens iemand kan inschrijven, is het niet meer een bewuste actie van de gebruiker. Dan wil ik graag een bevestiging per mail.
En een overzicht op de website met "Mijn inschrijvingen"?

@Matthijsy Is dit iets wat gebruikt gaat worden? Is prima mogelijk om te bouwen maar denk dat een zelfafrekend systeem hem bij Alpha niet gaat worden. Daarbij wordt er op de activiteit vaak toch een nieuw lijstje gemaakt en ben ik bang dat bestuurders dat niet nog op de stek gaan verwerken.
@cmitz Ja! Ik zou het sowieso willen doen om een sluitend systeem wel mogelijk te maken voor de toekomst. En op hetzelfde vlak, ik zou ook nog mijn inschrijving willen aanpassen als de datum nog niet verstreken is....

I think email reminders would be useful, as I mentioned here: #32

A reminder would look like this: "Er zijn nog emails die gemodereerd moeten worden".

Perhaps that reminder would include the number of to-be-moderated emails, or maybe even the subject of the emails.

Currently, when an image is uploaded to a photo album that is larger than 4096x4096 pixels, an error is shown and the image is not processed. It would be nice if the API would automatically rescale larger images to this format, so it is not necessary to do it manually.

Currently we have a lot issues with the jsonapi resources. I would like to discus if it would be better to migrate to another serializers.

Currently we have the following issues

• No namespace support
• A lot of magic (things happening automatically)
• Issues with migrating to Active Storage

When we would migrate we could do things again more vanilla Rails instead of a lot automatically. Disadvantage would be that we probably will lose the full jsonapi spec (like all relationship endpoints) but we probably do not need all of this.

There are a few options.

jsonapi-rb (http://jsonapi-rb.org/)

As far as I can see from the documentation it looks like this can work mostly with rails without a lot of magic. However, the is not much documentation. The jsonapi-rails project is mainted. However, the jsonapi-rb project (which the rails project uses) is not updated since 2017.

Netflix fast_jsonapi (https://github.com/Netflix/fast_jsonapi)

This promises to be a fast serializer. This also works with rails without a lot of magic. However, since november 2018 there are only 3 documentation commits and no other commits. The deserialization needs to be done by hand, but we can do this with params.permit(..) so that shouldn't be a problem.

Blueprint (https://github.com/procore/blueprinter)

This is the most active project of those 3. It looks very flexible but I don't see anything about relationships (except including the full record). It also includes 'conditional fields' which is nice mainly for the user model (probably the other projects also include this, not sure)

I also see some disadvantages of those 3

• Manual definition of all routes (so the relationship routes are lost)
• No out of the box filter options (like filter[ids]=1,2,3)
• ... probably more

I would like to get some feedback about your ideas about JSON API resources and a possible alternative

How to reproduce

Add a new debit collection, by uploading a .csv file with a Byte Order Mark. (See https://www.w3.org/International/questions/qa-byte-order-mark and https://en.wikipedia.org/wiki/Byte_order_mark for a definition of the BOM)

Expected behaviour

This should function normally, the debit collection should be imported succesfully. The BOM character is a pain in the ass, but sadly it is allowed at the start of unicode files, so we should support its optional presence.

Current behaviour

If a BOM is present, it interferes with the values of the headers that are read from the csv file provided by the POST request to /v1/debit/collections
This causes an error, which results in an email which shows the following message:

Right now the export UI looks like this:

But I'd like to add one field:

When will you delete this export?

With a placeholder:

I will delete this export 2 weeks after the activity on the 12nd of this month.

Or something like that

Motivation

At the moment I still have a lot of questions when I see a database export email to privacy@. Most of the times the description is not very clear, and there has never been anyone that mentioned how long they will keep it. Asking for when it will be deleted forces a user to think of this.

When working on the screen anyway, we might rephrase the wording of the "Reason of the export" to provoke a more detailed description that is clear for everyone, also people not in the loop of the activities (like me).