csvalpha / amber-api Goto Github PK
View Code? Open in Web Editor NEWhttps://csvalpha.nl
License: MIT License
https://csvalpha.nl
License: MIT License
It would be nice if we could add birthdays of members to the ical calendar
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
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.
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.
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.
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
I would like to get some feedback about your ideas about JSON API resources and a possible alternative
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
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
Copied from alpha-banana-api(dutch):
Het verbeteren van het sturen van mails naar aanwezigen van een activiteit.
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.
Elke activiteit krijgt een uniek automatisch gegenereerde mail-alias welke semi-gemodereerd is waarmee alleen de organiserende commissie alle ingeschrevenen kan mailen.
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.
activities/{id}/form
It works
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.
Do a request to https://csvalpha.nl/api/v1/daily_verses
Get back the daily verse
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.
Should be deleted
Not possible
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)
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.
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:
See slack for a screenshot
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.
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.
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
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.
Currently we have some hardcoded mailadresses (like ict, mailbeheer, no-reply) in our code. Would be good to extract this to the configurations
The email should appear on the moderation page on the UI
The email doesn't reach the moderation page and is lost somewhere
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.
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.
Time.zone.now
on production, or check the Ical dataIt is in the current timezone
It is still in the summer time. Could probably be fixed by setting the timezone in the dockerfile
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.
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.
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.
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 (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.
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)
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.
The same happens for public articles
Both should show the same comments
Server sends a 401 unauthorized on the photocomment
Server sends a 401 unauthorized on the 'related' users at public article comments
It is created
You get a 422, without a clear error message
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.
Column | Group | viewable | create by board | create by user | required | default | |
---|---|---|---|---|---|---|---|
id | technical | always | no | no | yes | ||
username | technical | always | no | no | yes | ||
general | user_setting | yes | yes | yes | |||
first_name | general | always | yes | yes | yes | ||
last_name | general | always | yes | yes | yes | ||
last_name_prefix | general | always | yes | yes | yes | ||
birthday | general | user_setting | yes | yes | yes | ||
address | general | user_setting | yes | yes | yes | ||
postcode | general | user_setting | yes | yes | yes | ||
city | general | user_setting | yes | yes | yes | ||
phone_number | general | user_setting | yes | yes | yes | ||
study | general | user_setting | yes | yes | no | ||
start_study | general | user_setting | yes | yes | no | ||
food_preferences | general | user_settings | yes | yes | no | ||
vegetarian | general | user_settings | yes | yes | yes | ||
emergency_contact | protected | user/board | yes | yes | no | ||
emergency_number | protected | user/board | yes | yes | no | ||
picture_publication_preference | privacy | user/board | yes | yes | yes | always_aks | |
ifes_data_sharing_preference | privacy | user/board | no | yes | is_activated | null | |
info_in_almanak | privacy | user/board | no | yes | is_activated | null | |
almanak_subscription_preference | privacy | user/board | yes | yes | yes | paper | |
digtus_subscription_preference | privacy | user/board | yes | yes | yes | paper | |
user_details_sharing_preference | privacy | user/board | yes | yes | is_activated | null |
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'.
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.
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
1: Automatically really destroy deleted emails
2: Automatically really destroy ignored (old) emails
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.
My suggestion is to execute a CleanupExpiredStoredMailsJob every day, that:
really_destroy!
s 2-week-old soft-deleted emailsdestroy
4 days old ignored emailsThat 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.
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):
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:
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 ;)
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.
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
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.
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
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).
Spreadsheet is parsed and cells with €0,- are ignored.
Amounts of €0,- are formatted as "€ -", which fails to parse, so the upload fails
You can upload an image
Has to be uploaded on an external image host
Upload a photo with the copyright (©) symbol in the Copyright Notice EXIF data field to an album.
The photo is uploaded and a green checkmark is shown
The photo is uploaded, but a 500 error is shown and an Encoding::UndefinedConversionError
is thrown
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.
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
Would like what you all think about this
Currently JSONAPI headers are disabled as it does not work in rspec and there is no docuementation to get it working
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....
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.
You can find them by clicking through the pages
You can only find the using the search function
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
The selected date of the album is shown in the photo album overview
The date before the selected date is shown
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.