{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":158970323,"defaultBranch":"master","name":"zulip","ownerLogin":"mateuszmandera","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2018-11-24T20:16:27.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/45007152?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1726777192.0","currentOid":""},"activityList":{"items":[{"before":"6589afdd6c31a04c6bbae9c0d11800c5d0b26e95","after":"f9b085ed53fe332d748b27b17a8d638d8d32f293","ref":"refs/heads/retention-limit-ids-list","pushedAt":"2024-09-19T22:55:23.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"retention: Limit number of ids passed to db in delete messages query.\n\nIf do_delete_messages (and friends) are called for a massive number of\nmessages, the giant list of message ids is passed to Postgres even\nthough chunk_size makes all but the first chunk_size of message ids\nuseless.","shortMessageHtmlLink":"retention: Limit number of ids passed to db in delete messages query."}},{"before":"e6c3eb48fbfe59dcd6ee78f16c8befbaacaa92c6","after":"6589afdd6c31a04c6bbae9c0d11800c5d0b26e95","ref":"refs/heads/retention-limit-ids-list","pushedAt":"2024-09-19T20:27:37.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"retention: Limit number of ids passed to db in delete messages query.\n\nIf do_delete_messages (and friends) are called for a massive number of\nmessages, the giant list of message ids is passed to Postgres even\nthough chunk_size makes all but the first chunk_size of message ids\nuseless.","shortMessageHtmlLink":"retention: Limit number of ids passed to db in delete messages query."}},{"before":null,"after":"e6c3eb48fbfe59dcd6ee78f16c8befbaacaa92c6","ref":"refs/heads/retention-limit-ids-list","pushedAt":"2024-09-19T20:19:52.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"retention: Limit number of ids passed to db in delete messages query.\n\nIf do_delete_messages (and friends) are called for a massive number of\nmessages, the giant list of message ids is passed to Postgres even\nthough chunk_size makes all but the first chunk_size of message ids\nuseless.","shortMessageHtmlLink":"retention: Limit number of ids passed to db in delete messages query."}},{"before":null,"after":"43dd696d39b6117522a5605137e97a642a8cf5d0","ref":"refs/heads/import-slack-connect-quirk","pushedAt":"2024-09-19T18:23:48.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"signup: Mirror dummy user should be registered with role from invite.\n\nAside of what's generally explained in the code comment, this is\nmotivated by the specific situation of import of Slack Connect channels.\nThese channels contain users who are \"external collaborators\" and\nlimited to a single channel in Slack. We don't have more sophisticated\nhandling of their import, which would map this concept 1-to-1 in Zulip -\nbut we create them as inactive dummy users, meaning they have to go\nthrough signup before their account is usable.\n\nThe issue is that their imported UserProfile.role is set to Member and\nwhen they register, the UserProfile gets reactivated with that role\nunchanged. However, if e.g. the user is signing up after they received\nan invitation from the admin, they should get the role that was\nconfigured on the invite. In particular important if the user is meant\nto still be \"limited\" and thus the admin invites them as a guest - they\ndefinitely don't want the user to get a full Member account because of\nthis weird interaction between import and registration.","shortMessageHtmlLink":"signup: Mirror dummy user should be registered with role from invite."}},{"before":"f4d518fb894b9e3cc32da714ff5fefe4108ae153","after":"a36f906d1ac564ce418874a091a67d7c3ebee07d","ref":"refs/heads/presence-history-limit-days","pushedAt":"2024-09-10T20:16:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"timabbott","name":"Tim Abbott","path":"/timabbott","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2746074?s=80&v=4"},"commit":{"message":"presence: Add history_limit_days param to the API.\n\nThis param allows clients to specify how much presence history they want\nto fetch. Previously, the server always returned 14 days of history.\nWith the recent migration of the presence API to the much more efficient\nsystem relying on incremental fetches via the last_update_id param added\nin #29999, we can now afford to provide much more history to clients\nthat request it - as all that historical data will only be fetched once.\n\nThere are three endpoints involved:\n- `/register` - this is the main useful endpoint for this, used by API\nclients to fetch initial data and register an events queue. Clients can\npass the `presence_history_limit_days` param here.\n- `/users/me/presence` - this endpoint is currently used by clients to\nupdate their presence status and fetch incremental data, making the new\nfunctionality not particularly useful here. However, we still add the\nnew `history_limit_days` param here, in case in the future clients\ntransition to using this also for the initial presence data fetch.\n- `/` - used when opening the webapp. Naturally, params aren't passed\nhere, so the server just assumes a value from\n`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns\ninformation about this default value in page_params.","shortMessageHtmlLink":"presence: Add history_limit_days param to the API."}},{"before":"b14c3314a7745b7a64b4814d2f9313d9dc39ef35","after":"95d8dfcb5a85ed661f7b87ba58fd8d2c267a85b0","ref":"refs/heads/message-type-recipient-type","pushedAt":"2024-09-10T19:23:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"zerver: Rename some message_type variables to recipient_type.","shortMessageHtmlLink":"zerver: Rename some message_type variables to recipient_type."}},{"before":null,"after":"b14c3314a7745b7a64b4814d2f9313d9dc39ef35","ref":"refs/heads/message-type-recipient-type","pushedAt":"2024-09-10T18:48:20.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"zerver: Rename some message_type variables to recipient_type.","shortMessageHtmlLink":"zerver: Rename some message_type variables to recipient_type."}},{"before":"84da920b5da8337cfef755f6dab66dcff71aebea","after":"c4bf67cb0368242f967aa6c3c5693deb19485fb4","ref":"refs/heads/retention-old-event-format","pushedAt":"2024-09-10T18:09:22.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"test_retention: Delete irrelevant comment.\n\nThis comment is clearly out of place and at this point doesn't match any\nof the classes in a useful way.","shortMessageHtmlLink":"test_retention: Delete irrelevant comment."}},{"before":null,"after":"84da920b5da8337cfef755f6dab66dcff71aebea","ref":"refs/heads/retention-old-event-format","pushedAt":"2024-09-10T18:03:12.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"retention: Remove outdated compat block for delete_message events.\n\nAs noted in the comment in that block, this is no longer useful.","shortMessageHtmlLink":"retention: Remove outdated compat block for delete_message events."}},{"before":"6362c9f45f18a81ceb31935aea7371d06f8b92e0","after":"f4d518fb894b9e3cc32da714ff5fefe4108ae153","ref":"refs/heads/presence-history-limit-days","pushedAt":"2024-09-06T22:54:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"presence: Add history_limit_days param to the API.\n\nThis param allows clients to specify how much presence history they want\nto fetch. Previously, the server always returned 14 days of history.\nWith the recent migration of the presence API to the much more efficient\nsystem relying on incremental fetches via the last_update_id param added\nin #29999, we can now afford to provide much more history to clients\nthat request it - as all that historical data will only be fetched once.\n\nThere are three endpoints involved:\n- `/register` - this is the main useful endpoint for this, used by API\nclients to fetch initial data and register an events queue. Clients can\npass the `presence_history_limit_days` param here.\n- `/users/me/presence` - this endpoint is currently used by clients to\nupdate their presence status and fetch incremental data, making the new\nfunctionality not particularly useful here. However, we still add the\nnew `history_limit_days` param here, in case in the future clients\ntransition to using this also for the initial presence data fetch.\n- `/` - used when opening the webapp. Naturally, params aren't passed\nhere, so the server just assumes a value from\n`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns\ninformation about this default value in page_params.","shortMessageHtmlLink":"presence: Add history_limit_days param to the API."}},{"before":"f01c5e81561d4a2d54d40e24fa5881a265f97ff4","after":"6362c9f45f18a81ceb31935aea7371d06f8b92e0","ref":"refs/heads/presence-history-limit-days","pushedAt":"2024-09-06T22:33:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"presence: Add history_limit_days param to the API.\n\nThis param allows clients to specify how much presence history they want\nto fetch. Previously, the server always returned 14 days of history.\nWith the recent migration of the presence API to the much more efficient\nsystem relying on incremental fetches via the last_update_id param added\nin #29999, we can now afford to provide much more history to clients\nthat request it - as all that historical data will only be fetched once.\n\nThere are three endpoints involved:\n- `/register` - this is the main useful endpoint for this, used by API\nclients to fetch initial data and register an events queue. Clients can\npass the `presence_history_limit_days` param here.\n- `/users/me/presence` - this endpoint is currently used by clients to\nupdate their presence status and fetch incremental data, making the new\nfunctionality not particularly useful here. However, we still add the\nnew `history_limit_days` param here, in case in the future clients\ntransition to using this also for the initial presence data fetch.\n- `/` - used when opening the webapp. Naturally, params aren't passed\nhere, so the server just assumes a value from\n`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns\ninformation about this default value in page_params.","shortMessageHtmlLink":"presence: Add history_limit_days param to the API."}},{"before":"a76838858dbdfa55eb768f76286e97d11fa929e7","after":"f01c5e81561d4a2d54d40e24fa5881a265f97ff4","ref":"refs/heads/presence-history-limit-days","pushedAt":"2024-09-05T23:20:57.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"timabbott","name":"Tim Abbott","path":"/timabbott","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2746074?s=80&v=4"},"commit":{"message":"presence: Add history_limit_days param to the API.\n\nThis param allows clients to specify how much presence history they want\nto fetch. Previously, the server always returned 14 days of history.\nWith the recent migration of the presence API to the much more efficient\nsystem relying on incremental fetches via the last_update_id param added\nin #29999, we can now afford to provide much more history to clients\nthat request it - as all that historical data will only be fetched once.\n\nThere are three endpoints involved:\n- `/register` - this is the main useful endpoint for this, used by API\nclients to fetch initial data and register an events queue. Clients can\npass the `presence_history_limit_days` param here.\n- `/users/me/presence` - this endpoint is currently used by clients to\nupdate their presence status and fetch incremental data, making the new\nfunctionality not particularly useful here. However, we still add the\nnew `history_limit_days` param here, in case in the future clients\ntransition to using this also for the initial presence data fetch.\n- `/` - used when opening the webapp. Naturally, params aren't passed\nhere, so the server just assumes a value from\n`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns\ninformation about this default value in page_params.","shortMessageHtmlLink":"presence: Add history_limit_days param to the API."}},{"before":"921b204cd5a883d96361ed886ebafd57ba055d47","after":"eb444eb0f581fc6a78424ff1b77f41b9f5ff6431","ref":"refs/heads/do-change-misc-permission-log","pushedAt":"2024-09-05T21:35:40.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"users: Add API endpoint to update_user_backend by real email.\n\nThe old endpoint for updating a user worked only via user id. Now we add\na different entry to this functionality, fetching the user by\n.delivery_email.\n\nupdate_user_backend becomes the main function handling all the logic,\ninvoked by the two endpoints.","shortMessageHtmlLink":"users: Add API endpoint to update_user_backend by real email."}},{"before":"c1846fe30f1b70bb68ce80491de90c06edb789cd","after":"921b204cd5a883d96361ed886ebafd57ba055d47","ref":"refs/heads/do-change-misc-permission-log","pushedAt":"2024-09-05T01:33:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"users: Add API endpoint to update_user_backend by real email.\n\nThe old endpoint for updating a user worked only via user id. Now we add\na different entry to this functionality, fetching the user by\n.delivery_email.\n\nupdate_user_backend becomes the main function handling all the logic,\ninvoked by the two endpoints.","shortMessageHtmlLink":"users: Add API endpoint to update_user_backend by real email."}},{"before":"ab9108e7cf7266ec19ac8058c82e4729b3055bfc","after":"c1846fe30f1b70bb68ce80491de90c06edb789cd","ref":"refs/heads/do-change-misc-permission-log","pushedAt":"2024-09-05T01:17:56.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"users: Add API endpoint to update_user_backend by real email.\n\nThe old endpoint for updating a user worked only via user id. Now we add\na different entry to this functionality, fetching the user by\n.delivery_email.\n\nupdate_user_backend becomes the main function handling all the logic,\ninvoked by the two endpoints.","shortMessageHtmlLink":"users: Add API endpoint to update_user_backend by real email."}},{"before":"2914c0c28fc8a4f6cc832f8df4f37f03f3233e15","after":"ab9108e7cf7266ec19ac8058c82e4729b3055bfc","ref":"refs/heads/do-change-misc-permission-log","pushedAt":"2024-09-05T00:49:01.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"users: Add API endpoint to update_user_backend by real email.\n\nThe old endpoint for updating a user worked only via user id. Now we add\na different entry to this functionality, fetching the user by\n.delivery_email.\n\nupdate_user_backend becomes the main function handling all the logic,\ninvoked by the two endpoints.","shortMessageHtmlLink":"users: Add API endpoint to update_user_backend by real email."}},{"before":"f11a33234552223e75329ab614d7e40dd340b7ec","after":"2914c0c28fc8a4f6cc832f8df4f37f03f3233e15","ref":"refs/heads/do-change-misc-permission-log","pushedAt":"2024-09-05T00:36:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"users: Add API endpoint to update_user_backend by real email.\n\nThe old endpoint for updating a user worked only via user id. Now we add\na different entry to this functionality, fetching the user by\n.delivery_email.\n\nupdate_user_backend becomes the main function handling all the logic,\ninvoked by the two endpoints.","shortMessageHtmlLink":"users: Add API endpoint to update_user_backend by real email."}},{"before":"05a2aeecedd269e8883082aecea28c092b7b1687","after":"f11a33234552223e75329ab614d7e40dd340b7ec","ref":"refs/heads/do-change-misc-permission-log","pushedAt":"2024-09-05T00:09:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"users: Add API endpoint to update_user_backend by real email.\n\nThe old endpoint for updating a user worked only via user id. Now we add\na different entry to this functionality, fetching the user by\n.delivery_email.\n\nupdate_user_backend becomes the main function handling all the logic,\ninvoked by the two endpoints.","shortMessageHtmlLink":"users: Add API endpoint to update_user_backend by real email."}},{"before":"1f7935a1538ea24b4d653849d798513c8d41c01e","after":"05a2aeecedd269e8883082aecea28c092b7b1687","ref":"refs/heads/do-change-misc-permission-log","pushedAt":"2024-09-05T00:07:04.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"users: Add API endpoint to update_user_backend by real email.\n\nThe old endpoint for updating a user worked only via user id. Now we add\na different entry to this functionality, fetching the user by\n.delivery_email.\n\nupdate_user_backend becomes the main function handling all the logic,\ninvoked by the two endpoints.","shortMessageHtmlLink":"users: Add API endpoint to update_user_backend by real email."}},{"before":"64fe6987ca6172e8d32303b4aad860fc68381b9e","after":"1f7935a1538ea24b4d653849d798513c8d41c01e","ref":"refs/heads/do-change-misc-permission-log","pushedAt":"2024-09-04T23:59:32.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"users: Add API endpoint do update_user_backend by real email.\n\nThe old endpoint for updating a user worked only via user id. Now we add\na different entry to this functionality, fetching the user by\n.delivery_email.\n\nupdate_user_backend becomes the main function handling all the logic,\ninvoked by the two endpoints.","shortMessageHtmlLink":"users: Add API endpoint do update_user_backend by real email."}},{"before":"6dc0f8bbd952c2a93e4b75e952d1699049e05688","after":"64fe6987ca6172e8d32303b4aad860fc68381b9e","ref":"refs/heads/do-change-misc-permission-log","pushedAt":"2024-09-04T23:53:44.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"users: Add API endpoint do update_user_backend by real email.\n\nThe old endpoint for updating a user worked only via user id. Now we add\na different entry to this functionality, fetching the user by\n.delivery_email.\n\nupdate_user_backend becomes the main function handling all the logic,\ninvoked by the two endpoints.","shortMessageHtmlLink":"users: Add API endpoint do update_user_backend by real email."}},{"before":"dad0f4fb39fc59aadd29c31b0db3e76c5f87d9ee","after":"a76838858dbdfa55eb768f76286e97d11fa929e7","ref":"refs/heads/presence-history-limit-days","pushedAt":"2024-08-30T22:04:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"presence: Add history_limit_days param to the API.\n\nThis param allows clients to specify how much presence history they want\nto fetch. Previously, the server always returned 14 days of history.\nWith the recent migration of the presence API to the much more efficient\nsystem relying on incremental fetches via the last_update_id param added\nin #29999, we can now afford to provide much more history to clients\nthat request it - as all that historical data will only be fetched once.\n\nThere are three endpoints involved:\n- `/register` - this is the main useful endpoint for this, used by API\nclients to fetch initial data and register an events queue. Clients can\npass the `presence_history_limit_days` param here.\n- `/users/me/presence` - this endpoint is currently used by clients to\nupdate their presence status and fetch incremental data, making the new\nfunctionality not particularly useful here. However, we still add the\nnew `history_limit_days` param here, in case in the future clients\ntransition to using this also for the initial presence data fetch.\n- `/` - used when opening the webapp. Naturally, params aren't passed\nhere, so the server just assumes a value from\n`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns\ninformation about this default value in page_params.","shortMessageHtmlLink":"presence: Add history_limit_days param to the API."}},{"before":"9288550da5f2fae1a6c30e9be51c279a79bd3335","after":"dad0f4fb39fc59aadd29c31b0db3e76c5f87d9ee","ref":"refs/heads/presence-history-limit-days","pushedAt":"2024-08-30T21:42:28.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"presence: Add history_limit_days param to the API.\n\nThis param allows clients to specify how much presence history they want\nto fetch. Previously, the server always returned 14 days of history.\nWith the recent migration of the presence API to the much more efficient\nsystem relying on incremental fetches via the last_update_id param added\nin #29999, we can now afford to provide much more history to clients\nthat request it - as all that historical data will only be fetched once.\n\nThere are three endpoints involved:\n- `/register` - this is the main useful endpoint for this, used by API\nclients to fetch initial data and register an events queue. Clients can\npass the `presence_history_limit_days` param here.\n- `/users/me/presence` - this endpoint is currently used by clients to\nupdate their presence status and fetch incremental data, making the new\nfunctionality not particularly useful here. However, we still add the\nnew `history_limit_days` param here, in case in the future clients\ntransition to using this also for the initial presence data fetch.\n- `/` - used when opening the webapp. Naturally, params aren't passed\nhere, so the server just assumes a value from\n`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns\ninformation about this default value in page_params.","shortMessageHtmlLink":"presence: Add history_limit_days param to the API."}},{"before":"3ab4c52d88fddb0aab3adfc887373503970e935d","after":"9288550da5f2fae1a6c30e9be51c279a79bd3335","ref":"refs/heads/presence-history-limit-days","pushedAt":"2024-08-29T23:00:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"presence: Add history_limit_days param to the API.\n\nThis param allows clients to specify how much presence history they want\nto fetch. Previously, the server always returned 14 days of history.\nWith the recent migration of the presence API to the much more efficient\nsystem relying on incremental fetches via the last_update_id param added\nin #29999, we can now afford to provide much more history to clients\nthat request it - as all that historical data will only be fetched once.\n\nThere are three endpoints involved:\n- `/register` - this is the main useful endpoint for this, used by API\nclients to fetch initial data and register an events queue. Clients can\npass the `presence_history_limit_days` param here.\n- `/users/me/presence` - this endpoint is currently used by clients to\nupdate their presence status and fetch incremental data, making the new\nfunctionality not particularly useful here. However, we still add the\nnew `history_limit_days` param here, in case in the future clients\ntransition to using this also for the initial presence data fetch.\n- `/` - used when opening the webapp. Naturally, params aren't passed\nhere, so the server just assumes a value from\n`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns\ninformation about this default value in page_params.","shortMessageHtmlLink":"presence: Add history_limit_days param to the API."}},{"before":null,"after":"3ab4c52d88fddb0aab3adfc887373503970e935d","ref":"refs/heads/presence-history-limit-days","pushedAt":"2024-08-29T22:56:30.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"presence: Add history_limit_days param to the API.\n\nThis param allows clients to specify how much presence history they want\nto fetch. Previously, the server always returned 14 days of history.\nWith the recent migration of the presence API to the much more efficient\nsystem relying on incremental fetches via the last_update_id param added\nin #29999, we can now afford to provide much more history to clients\nthat request it - as all that historical data will only be fetched once.\n\nThere are three endpoints involved:\n- `/register` - this is the main useful endpoint for this, used by API\nclients to fetch initial data and register an events queue. Clients can\npass the `presence_history_limit_days` param here.\n- `/users/me/presence` - this endpoint is currently used by clients to\nupdate their presence status and fetch incremental data, making the new\nfunctionality not particularly useful here. However, we still add the\nnew `history_limit_days` param here, in case in the future clients\ntransition to using this also for the initial presence data fetch.\n- `/` - used when opening the webapp. Naturally, params aren't passed\nhere, so the server just assumes a value from\n`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns\ninformation about this default value in page_params.","shortMessageHtmlLink":"presence: Add history_limit_days param to the API."}},{"before":"4647af4835e33405b51e4c6e36b7f7524ebeb7f6","after":"f9907da2405939dfa7d532903cee8682ac4cb84b","ref":"refs/heads/saml-sync-role","pushedAt":"2024-08-20T18:25:59.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"timabbott","name":"Tim Abbott","path":"/timabbott","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/2746074?s=80&v=4"},"commit":{"message":"docs: Clean up discussion of very old versions.","shortMessageHtmlLink":"docs: Clean up discussion of very old versions."}},{"before":"5e1f09e9bb3e3f853fcacb82956cceaff0f67ec3","after":"4647af4835e33405b51e4c6e36b7f7524ebeb7f6","ref":"refs/heads/saml-sync-role","pushedAt":"2024-08-19T00:00:04.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"saml: Fix exception when syncing missing value to custom profile field.\n\nThere was a bug here that would trigger an exception inside\n`sync_user_profile_custom_fields`, causing it to get logged with\nlogging.warning, when an attribute configured for SAML custom profile\nfield sync was missing from a SAMLResponse or had an empty value.\n`sync_user_profile_custom_fields` expects valid values, and None is not\nvalid.\n\nWe could consider a slightly different behavior here instead - when an\nattribute is sent with no value in the SAMLResponse, that means the attr\nhas no value in the IdP's user directory - so perhaps a better behavior\nwould be to also remove the custom profile field value in Zulip. However\nthere are two issues with that:\n\n1. It's not necessarily the best behavior, because an organization might\nwant the \"user doesn't have this attribute set at the IdP level\" state\nto just mean that the user should be free to set the value manually in\nZulip if they wish. And having that value get reset on every login would\nthen be an issue. The implementation in this commit is consistent with\nthis philosophy.\n\n2. There's some implementation difficulty - upstream\n`self.get_attr(...)`, which we use for reading the attr value from the\nSAMLResponse, doesn't distinguish between an attribute being sent with\nno value and the attribute not being sent at all - in both cases it\nreturns None. So we'd need some extra work here with parsing the\nSAMLResponse properly, to be able to know when the custom profile field\nshould get cleared.","shortMessageHtmlLink":"saml: Fix exception when syncing missing value to custom profile field."}},{"before":"0ab6d07d3ef962ac23554d3cf362b6825064c1f4","after":"5e1f09e9bb3e3f853fcacb82956cceaff0f67ec3","ref":"refs/heads/saml-sync-role","pushedAt":"2024-08-17T18:42:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"saml: Add documentation about user role/custom profile fields sync.","shortMessageHtmlLink":"saml: Add documentation about user role/custom profile fields sync."}},{"before":"f802e8da1768536ecbc2d3c534848d0d999a0b23","after":"0ab6d07d3ef962ac23554d3cf362b6825064c1f4","ref":"refs/heads/saml-sync-role","pushedAt":"2024-08-17T00:21:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"saml: Add support for syncing user role.\n\nReplace the SOCIAL_AUTH_SYNC_CUSTOM_ATTRS_DICT with\nSOCIAL_AUTH_SYNC_ATTRS_DICT, designed to support also regular user attrs\nlike role or full name (in the future).\n\nCustom attributes can stay configured as they were and will get merged\ninto SOCIAL_AUTH_SYNC_ATTRS_DICT in computed_settings, or can be\nspecified in SOCIAL_AUTH_SYNC_ATTRS_DICT directly with \"custom__\"\nprefix.\n\nThe role sync is plumbed through to user creation, so users can\nimmediately be created with their intended role as provided by the IdP\nwhen they're creating their account, even when doing this flow without\nan invitiation.","shortMessageHtmlLink":"saml: Add support for syncing user role."}},{"before":"1ad7dc1335b7c4746c85e49b45c279b45fe93e4f","after":"f802e8da1768536ecbc2d3c534848d0d999a0b23","ref":"refs/heads/saml-sync-role","pushedAt":"2024-08-17T00:19:25.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mateuszmandera","name":"Mateusz Mandera","path":"/mateuszmandera","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45007152?s=80&v=4"},"commit":{"message":"saml: Add support for syncing user role.\n\nReplace the SOCIAL_AUTH_SYNC_CUSTOM_ATTRS_DICT with\nSOCIAL_AUTH_SYNC_ATTRS_DICT, designed to support also regular user attrs\nlike role or full name (in the future).\n\nCustom attributes can stay configured as they were and will get merged\ninto SOCIAL_AUTH_SYNC_ATTRS_DICT in computed_settings, or can be\nspecified in SOCIAL_AUTH_SYNC_ATTRS_DICT directly with \"custom__\"\nprefix.\n\nThe role sync is plumbed through to user creation, so users can\nimmediately be created with their intended role as provided by the IdP\nwhen they're creating their account, even when doing this flow without\nan invitiation.","shortMessageHtmlLink":"saml: Add support for syncing user role."}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEu2K57gA","startCursor":null,"endCursor":null}},"title":"Activity · mateuszmandera/zulip"}