{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":39152554,"defaultBranch":"master","name":"consuldemocracy","ownerLogin":"consuldemocracy","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2015-07-15T18:04:16.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/14167322?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1716215946.0","currentOid":""},"activityList":{"items":[{"before":"ea4480d96742873c40ae73594cfef58b3389974c","after":"a1f0b378a345d924a1492a04e407eba8253f4e9c","ref":"refs/heads/i18n_master","pushedAt":"2024-05-23T02:44:32.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ConsulBot","name":"Consul Bot","path":"/ConsulBot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/30019168?s=80&v=4"},"commit":{"message":"New translations admin.yml (Swedish)","shortMessageHtmlLink":"New translations admin.yml (Swedish)"}},{"before":"70ef1ebc0aed17bc0a104bb54169a568055fa797","after":"ea4480d96742873c40ae73594cfef58b3389974c","ref":"refs/heads/i18n_master","pushedAt":"2024-05-23T01:27:10.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"ConsulBot","name":"Consul Bot","path":"/ConsulBot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/30019168?s=80&v=4"},"commit":{"message":"New translations admin.yml (Swedish)","shortMessageHtmlLink":"New translations admin.yml (Swedish)"}},{"before":"c009fa378fb0f78196cb1f50aaf7c315c1fae89f","after":"a606986b5c46dea4c57d9e8197cea70bd4479047","ref":"refs/heads/tenant_locales","pushedAt":"2024-05-21T00:01:44.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Extract model to handle locales settings\n\nThis way we can simplify the view, particularly the form. However, we're\nstill adding some complexity to the form so inputs are inside labels and\nso the collection is easier to style with CSS.","shortMessageHtmlLink":"Extract model to handle locales settings"}},{"before":"cf6556934c8f0d8dfe5d217411cf335ec5171ed4","after":"578d6fc56b918b9cca4a437f5021a712f1e2caef","ref":"refs/heads/rails7.1","pushedAt":"2024-05-20T22:41:40.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Use Object#with","shortMessageHtmlLink":"Use Object#with"}},{"before":"8f029a4284a86f675c44895fe057988c9a8564db","after":"2a01cccd9df220d329d591661bf15b4049182c03","ref":"refs/heads/use_rails7.0_methods","pushedAt":"2024-05-20T22:39:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Split polls date range validation\n\nIt was a bit strange to leave the end date blank and have a message\nassociated with the start date, so we're using presence validations\ninstead.\n\nFor the range validation, we're using the comparison validator included\nin Rails 7.0.","shortMessageHtmlLink":"Split polls date range validation"}},{"before":"2485e573a5ecc00594f1eaaa73d25e7bdc9daf38","after":"bef06fa41ca331a1e2fde37a12267e1efa500ecd","ref":"refs/heads/video_cookies","pushedAt":"2024-05-20T15:53:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Use the Do Not Track parameter in vimeo videos\n\nWith this parameter, Vimeo no longer uses cookies that identifies users\nbrowsing our site.\n\nThey do still store some cookies, though; quoting from Vimeo player\nparameters overview:\n\n> When DNT is enabled, Vimeo deploys one essential cookie via the\n> embeddable player:\n> The __cf_bm cookie, which is part of Cloudflare's Bot Management\n> service and helps mitigate risk associated with spam and bot traffic.\n\nNot sure whether this counts as essential cookies in our case; they're\nessential for Vimeo, but for us, they're third-party cookies, after all.\n\n[1] https://help.vimeo.com/hc/en-us/articles/12426260232977-Player-parameters-overview","shortMessageHtmlLink":"Use the Do Not Track parameter in vimeo videos"}},{"before":"78e50f50e3ba4a84d79ffdc1396905ef47f73277","after":"b39c401d437474e3057f6215029d15428aabda0a","ref":"refs/heads/check_all_none","pushedAt":"2024-05-20T15:27:35.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Move shared component stylesheets to shared folder\n\nWe had an inconsistency where most stylesheets associated to a component\nwould have the same relative path as their component, so if we had a\ncomponent in `app/components/admin/whatever`, its associated stylesheet\nwould be in `app/assets/stylesheets/admin/whatever`.\n\nThere was one exception to this rule: stylesheets for components in\n`app/components/shared/` were placed in `app/assets/stylesheets/`. The\nreason was that we thought \"well... if they're in the root folder,\nthey're shared\". However, this is confusing because in the root folder\nthere are also stylesheets that aren't associated to a component.\n\nSo we're creating the `app/assets/stylesheets/shared/` folder. This also\nmeans we don't have to manually add every stylesheet in this folder the\nthe `application.scss` file.\n\nWe aren't the same for JavaScript files because with JavaScript we still\ndon't have a clear association between JavaScript files and components.\nOnly a couple of them (`advanced_search.js` and `check_all_none.js`)\nwould be good candidates, and the one for the advanced search form\ndoesn't even use the `.advanced-search-form` selector that we use in the\nCSS file.","shortMessageHtmlLink":"Move shared component stylesheets to shared folder"}},{"before":"e9be45e8dcdfb91f88652229c9a3eb216fee9fda","after":"bd56eb956809bdd9a077aba8edb4e160d289cff2","ref":"refs/heads/empty_cache_when_upgrading","pushedAt":"2024-05-20T15:27:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Clear Rails cache when upgrading Consul Democracy\n\nWe use caching in our application in two different ways:\n\n1. Rails.cache.fetch in models/controllers/libraries\n2. Fragment caching in the views\n\nWhen using Rails.cache.fetch, we usually set an expiration date or\nprovide a precise way to invalidate it. If the code changes and the\ninformation stored in the cache is different from what the new code\nwould return, it's usually not a big deal because the cache will expire\nin an hour or a day. Until commit , the statistics\nwere an exception to this rule, but that's no longer the case. The\nactual exception to this rule are the i18n translations, but the code\ncaching them is very simple and hasn't changed for more than three years\n(when it was written for the first time).\n\nWhen using fragment caching, on the other hand, Rails automatically\ninvalidates the cache when the associated _view code_ changes. That is,\nif a view contains cache, the view renders a partial, and the partial\nchanges, the cache is correctly invalidated. The cache isn't invalidated\nwhen the code in helpers, models or controllers change, though, which\nthe Rails team considers a compromise solution.\n\nHowever, we've been moving view partials (and even views) to components,\nand the cache isn't invalidated when a component changes (it doesn't\nmatter whether the component Ruby file or the component ERB file\nchanges). That means that the cache will keep rendering the HTML\ngenerated by the old code.\n\nSo, now, we're clearing the cache when upgrading to a new version of\nConsul Democracy, as part of the release tasks. That way, institutions\nupgrading to a new version don't have to worry about possible issues\nwith the cache due to the new code not being executed.\n\nI was thinking of adding it to a Capistrano task, but that would mean\nthat every time people deploy new code, even if it's a hotfix that\ndoesn't affect the cache at all, the cache would be cleared, which could\nbe inconvenient. Doing it in a release, that usually changes thousands\nof lines of code, sounds like a good compromise.","shortMessageHtmlLink":"Clear Rails cache when upgrading Consul Democracy"}},{"before":"0727a1b82bb8c66f652503b45dd467730204e693","after":"c009fa378fb0f78196cb1f50aaf7c315c1fae89f","ref":"refs/heads/tenant_locales","pushedAt":"2024-05-20T15:26:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Extract model to handle locales settings\n\nThis way we can simplify the view, particularly the form. However, we're\nstill adding some complexity to the form so inputs are inside labels and\nso the collection is easier to style with CSS.","shortMessageHtmlLink":"Extract model to handle locales settings"}},{"before":"16f844595dd87be12f522857de8bcb66147c7a98","after":null,"ref":"refs/heads/budgets_stats_cache","pushedAt":"2024-05-20T14:39:06.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"}},{"before":"fe415d8367eeb148cb97cf05be7e7bad341200f1","after":"bb9e47579e988a36bd8e1972bd16a693ee439438","ref":"refs/heads/master","pushedAt":"2024-05-20T14:39:05.000Z","pushType":"pr_merge","commitsCount":10,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Merge pull request #5456 from consuldemocracy/budgets_stats_cache\n\nDon't use the cache in admin budget stats","shortMessageHtmlLink":"Merge pull request #5456 from consuldemocracy/budgets_stats_cache"}},{"before":"ba6c18663d91e0878782a7c7739d30b30560be86","after":"16f844595dd87be12f522857de8bcb66147c7a98","ref":"refs/heads/budgets_stats_cache","pushedAt":"2024-05-20T14:19:47.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Don't use the cache in admin budget stats\n\nIn commit e51e03446, we started using the same code to show stats in the\npublic area and in the admin area. However, in doing so we introduced a\nbug, since stats in the public area are only shown after a certain part\nof the process has finished, meaning the stats appearing on the page\nnever change (in theory), so it's perfectly fine to cache them. However,\nin the admin area stats can be accessed while the process is still\nongoing, so caching the stats will lead to the wrong results being\ndisplayed.\n\nWe've thought about expiring the cache when new supports or ballot lines\nare added; however, that means the methods calculating the stats for the\nsupporting phase would expire when supports are added/removed but the\nmethods calculating the stats for the voting phase would expire when\nballot lines are added/removed. It gets even more complex because the\n`headings` method calculates stats for both the supporting and the\nvoting phases.\n\nSo, since loading stats in the admin section is fast even without the\ncache because they only load very basic statistics, we're taking the\nsimple approach of disabling the cache in this case, so everything works\nthe same way it did before commit e51e03446.\n\nCo-authored-by: Javi Martín ","shortMessageHtmlLink":"Don't use the cache in admin budget stats"}},{"before":"ba6c18663d91e0878782a7c7739d30b30560be86","after":null,"ref":"refs/heads/remove_budgets_admin_stats_cache","pushedAt":"2024-05-20T14:18:39.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"}},{"before":"301ecb171aa2981d740bd92730ce4b9e8524924f","after":"ba6c18663d91e0878782a7c7739d30b30560be86","ref":"refs/heads/budgets_stats_cache","pushedAt":"2024-05-20T14:17:58.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Don't use the cache in admin budget stats\n\nIn commit e51e03446, we started using the same code to show stats in the\npublic area and in the admin area. However, in doing so we introduced a\nbug, since stats in the public area are only shown after a certain part\nof the process has finished, meaning the stats appearing on the page\nnever change (in theory), so it's perfectly fine to cache them. However,\nin the admin area stats can be accessed while the process is still\nongoing, so caching the stats will lead to the wrong results being\ndisplayed.\n\nWe've thought about expiring the cache when new supports or ballot lines\nare added; however, that means the methods calculating the stats for the\nsupporting phase would expire when supports are added/removed but the\nmethods calculating the stats for the voting phase would expire when\nballot lines are added/removed. It gets even more complex because the\n`headings` method calculates stats for both the supporting and the\nvoting phases.\n\nSo, since loading stats in the admin section is fast even without the\ncache because they only load very basic statistics, we're taking the\nsimple approach of disabling the cache in this case, so everything works\nthe same way it did before commit e51e03446.\n\nCo-authored-by: Javi Martín ","shortMessageHtmlLink":"Don't use the cache in admin budget stats"}},{"before":"31a7aabf228405519c7a14646886f2c7fa8f4a1a","after":"af5a4fdd5029aa76a5ecc800a076dade6dcc2a0b","ref":"refs/heads/demo-staging","pushedAt":"2024-05-19T21:59:04.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Change name in demo settings","shortMessageHtmlLink":"Change name in demo settings"}},{"before":null,"after":"2485e573a5ecc00594f1eaaa73d25e7bdc9daf38","ref":"refs/heads/video_cookies","pushedAt":"2024-05-19T21:44:43.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Use the Do Not Track parameter in vimeo videos\n\nWith this parameter, Vimeo no longer uses cookies that identifies users\nbrowsing our site.\n\nThey do still store some cookies, though; quoting from Vimeo player\nparameters overview:\n\n> When DNT is enabled, Vimeo deploys one essential cookie via the\n> embeddable player:\n> The __cf_bm cookie, which is part of Cloudflare's Bot Management\n> service and helps mitigate risk associated with spam and bot traffic.\n\nNot sure whether this counts as essential cookies in our case; they're\nessential for Vimeo, but for us, they're third-party cookies, after all.\n\n[1] https://help.vimeo.com/hc/en-us/articles/12426260232977-Player-parameters-overview","shortMessageHtmlLink":"Use the Do Not Track parameter in vimeo videos"}},{"before":"1220f63160bb4be93172dc477a79ec88cc787f71","after":"8f029a4284a86f675c44895fe057988c9a8564db","ref":"refs/heads/use_rails7.0_methods","pushedAt":"2024-05-19T03:37:30.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Split polls date range validation\n\nIt was a bit strange to leave the end date blank and have a message\nassociated with the start date, so we're using presence validations\ninstead.\n\nFor the range validation, we're using the comparison validator included\nin Rails 7.0.","shortMessageHtmlLink":"Split polls date range validation"}},{"before":"dd1bed5939df9b4eeed643447b638536d6750a6a","after":"31a7aabf228405519c7a14646886f2c7fa8f4a1a","ref":"refs/heads/demo-staging","pushedAt":"2024-05-19T01:38:51.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Change name in demo settings","shortMessageHtmlLink":"Change name in demo settings"}},{"before":"2514132a841310d88c5cf4990974f802145c1d74","after":"e9be45e8dcdfb91f88652229c9a3eb216fee9fda","ref":"refs/heads/empty_cache_when_upgrading","pushedAt":"2024-05-18T18:08:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Clear Rails cache when upgrading Consul Democracy\n\nWe use caching in our application in two different ways:\n\n1. Rails.cache.fetch in models/controllers/libraries\n2. Fragment caching in the views\n\nWhen using Rails.cache.fetch, we usually set an expiration date or\nprovide a precise way to invalidate it. If the code changes and the\ninformation stored in the cache is different from what the new code\nwould return, it's usually not a big deal because the cache will expire\nin an hour or a day. Until commit , the statistics\nwere an exception to this rule, but that's no longer the case. The\nactual exception to this rule are the i18n translations, but the code\ncaching them is very simple and hasn't changed for more than three years\n(when it was written for the first time).\n\nWhen using fragment caching, on the other hand, Rails automatically\ninvalidates the cache when the associated _view code_ changes. That is,\nif a view contains cache, the view renders a partial, and the partial\nchanges, the cache is correctly invalidated. The cache isn't invalidated\nwhen the code in helpers, models or controllers change, though, which\nthe Rails team considers a compromise solution.\n\nHowever, we've been moving view partials (and even views) to components,\nand the cache isn't invalidated when a component changes (it doesn't\nmatter whether the component Ruby file or the component ERB file\nchanges). That means that the cache will keep rendering the HTML\ngenerated by the old code.\n\nSo, now, we're clearing the cache when upgrading to a new version of\nConsul Democracy, as part of the release tasks. That way, institutions\nupgrading to a new version don't have to worry about possible issues\nwith the cache due to the new code not being executed.\n\nI was thinking of adding it to a Capistrano task, but that would mean\nthat every time people deploy new code, even if it's a hotfix that\ndoesn't affect the cache at all, the cache would be cleared, which could\nbe inconvenient. Doing it in a release, that usually changes thousands\nof lines of code, sounds like a good compromise.","shortMessageHtmlLink":"Clear Rails cache when upgrading Consul Democracy"}},{"before":"42fe27fa329ec4d9f6a81ce81f13c855ae494644","after":"2514132a841310d88c5cf4990974f802145c1d74","ref":"refs/heads/empty_cache_when_upgrading","pushedAt":"2024-05-18T01:50:14.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Clear Rails cache when upgrading Consul Democracy\n\nWe use caching in our application in two different ways:\n\n1. Rails.cache.fetch in models/controllers/libraries\n2. Fragment caching in the views\n\nWhen using Rails.cache.fetch, we usually set an expiration date or\nprovide a precise way to invalidate it. If the code changes and the\ninformation stored in the cache is different from what the new code\nwould return, it's usually not a big deal because the cache will expire\nin an hour or a day. Until commit , the statistics\nwere an exception to this rule, but that's no longer the case. The\nactual exception to this rule are the i18n translations, but the code\ncaching them is very simple and hasn't changed for more than three years\n(when it was written for the first time).\n\nWhen using fragment caching, on the other hand, Rails automatically\ninvalidates the cache when the associated _view code_ changes. That is,\nif a view contains cache, the view renders a partial, and the partial\nchanges, the cache is correctly invalidated. The cache isn't invalidated\nwhen the code in helpers, models or controllers change, though, which\nthe Rails team considers a compromise solution.\n\nHowever, we've been moving view partials (and even views) to components,\nand the cache isn't invalidated when a component changes (it doesn't\nmatter whether the component Ruby file or the component ERB file\nchanges). That means that the cache will keep rendering the HTML\ngenerated by the old code.\n\nSo, now, we're clearing the cache when upgrading to a new version of\nConsul Democracy, as part of the release tasks. That way, institutions\nupgrading to a new version don't have to worry about possible issues\nwith the cache due to the new code not being executed.\n\nI was thinking of adding it to a Capistrano task, but that would mean\nthat every time people deploy new code, even if it's a hotfix that\ndoesn't affect the cache at all, the cache would be cleared, which could\nbe inconvenient. Doing it in a release, that usually changes thousands\nof lines of code, sounds like a good compromise.","shortMessageHtmlLink":"Clear Rails cache when upgrading Consul Democracy"}},{"before":"7bd90eae4eede6d5a5c48001fec83feb39d91b21","after":"42fe27fa329ec4d9f6a81ce81f13c855ae494644","ref":"refs/heads/empty_cache_when_upgrading","pushedAt":"2024-05-18T01:01:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Clear Rails cache when upgrading Consul Democracy\n\nWe use caching in our application in two different ways:\n\n1. Rails.cache.fetch in models/controllers/libraries\n2. Fragment caching in the views\n\nWhen using Rails.cache.fetch, we usually set an expiration date or\nprovide a precise way to expire it. If the code changes and the\ninformation stored in the cache is different from what the new code\nwould return, it's usually not a big deal because the cache will expire\nin an hour or a day. Until commit , the statistics\nwere an exception to this rule, but that's no longer the case. The\nactual exception to this rule are the i18n translations, but the code\ncaching them is very simple and hasn't changed for more than three years\n(when it was written for the first time).\n\nWhen using fragment caching, on the other hand, Rails automatically\nexpires the cache when the associated _view code_ changes. That is, if a\nview contains cache, the view renders a partial, and the partial\nchanges, the cache is correctly expired. The cache isn't expired when\nthe code in helpers, models or controllers change, though, which the\nRails team considers a compromise solution.\n\nHowever, we've been moving view partials (and even views) to components,\nand the cache isn't expired when a component changes (it doesn't matter\nwhether the component Ruby file or the component ERB file changes). That\nmeans that the cache will keep rendering the HTML generated by the old\ncode.\n\nSo, now, we're clearing the cache when upgrading to a new version of\nConsul Democracy, as part of the release tasks. That way, institutions\nupgrading to a new version don't have to worry about possible issues\nwith the cache due to the new code not being executed.\n\nI was thinking of adding it to a Capistrano task, but that would mean\nthat every time people deploy new code, even if it's a hotfix that\ndoesn't affect the cache at all, the cache would be cleared, which could\nbe inconvenient. Doing it in a release, that usually changes thousands\nof lines of code, sounds like a good compromise.","shortMessageHtmlLink":"Clear Rails cache when upgrading Consul Democracy"}},{"before":null,"after":"7bd90eae4eede6d5a5c48001fec83feb39d91b21","ref":"refs/heads/empty_cache_when_upgrading","pushedAt":"2024-05-18T01:00:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Clear the cache when upgrading Consul Democracy\n\nWe use caching in our application in two different ways:\n\n1. Rails.cache.fetch in models/controllers/libraries\n2. Fragment caching in the views\n\nWhen using Rails.cache.fetch, we usually set an expiration date or\nprovide a precise way to expire it. If the code changes and the\ninformation stored in the cache is different from what the new code\nwould return, it's usually not a big deal because the cache will expire\nin an hour or a day. Until commit , the statistics\nwere an exception to this rule, but that's no longer the case. The\nactual exception to this rule are the i18n translations, but the code\ncaching them is very simple and hasn't changed for more than three years\n(when it was written for the first time).\n\nWhen using fragment caching, on the other hand, Rails automatically\nexpires the cache when the associated _view code_ changes. That is, if a\nview contains cache, the view renders a partial, and the partial\nchanges, the cache is correctly expired. The cache isn't expired when\nthe code in helpers, models or controllers change, though, which the\nRails team considers a compromise solution.\n\nHowever, we've been moving view partials (and even views) to components,\nand the cache isn't expired when a component changes (it doesn't matter\nwhether the component Ruby file or the component ERB file changes). That\nmeans that the cache will keep rendering the HTML generated by the old\ncode.\n\nSo, now, we're clearing the cache when upgrading to a new version of\nConsul Democracy, as part of the release tasks. That way, institutions\nupgrading to a new version don't have to worry about possible issues\nwith the cache due to the new code not being executed.\n\nI was thinking of adding it to a Capistrano task, but that would mean\nthat every time people deploy new code, even if it's a hotfix that\ndoesn't affect the cache at all, the cache would be cleared, which could\nbe inconvenient. Doing it in a release, that usually changes thousands\nof lines of code, sounds like a good compromise.","shortMessageHtmlLink":"Clear the cache when upgrading Consul Democracy"}},{"before":"df1b744455daf5dfc50f93afa369cf58780a388f","after":"091b24700af95327a6bcf08c686301dfedcae99f","ref":"refs/heads/add_option_id_to_poll_answers","pushedAt":"2024-05-17T21:20:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Delete duplicate records in different languages","shortMessageHtmlLink":"Delete duplicate records in different languages"}},{"before":"63b25c4c87faa96e26a9767eb08d933812a75b45","after":"be02718bfe754620587846c23dd6946025a90d67","ref":"refs/heads/poll_duplicate_voters","pushedAt":"2024-05-17T21:18:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Add a log file to track deleted duplicate records\n\nIt might be interesting in some cases to check the information related\nto those records.","shortMessageHtmlLink":"Add a log file to track deleted duplicate records"}},{"before":"d7efc4b7f2374cee4508c6daac5c55db07d03048","after":"63b25c4c87faa96e26a9767eb08d933812a75b45","ref":"refs/heads/poll_duplicate_voters","pushedAt":"2024-05-17T21:17:57.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Add a log file to track deleted duplicate records\n\nIt might be interesting in some cases to check the information related\nto those records.","shortMessageHtmlLink":"Add a log file to track deleted duplicate records"}},{"before":"98aec84e7459941c26305ab4306e5b46653c9649","after":"df1b744455daf5dfc50f93afa369cf58780a388f","ref":"refs/heads/add_option_id_to_poll_answers","pushedAt":"2024-05-17T20:51:13.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Delete duplicate records in different languages","shortMessageHtmlLink":"Delete duplicate records in different languages"}},{"before":"a4779f589b10dbb57cc36d74f99ebeaf6df11ce8","after":"32848715eedeb0d1ba17e6d9831f7803c1457826","ref":"refs/heads/rename_question_answer_to_option","pushedAt":"2024-05-17T20:50:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Rename Poll::Question::Answer to Poll::Question::Option\n\nHaving a class named `Poll::Question::Answer` and another class named\n`Poll::Answer` was so confusing that no developer working on the project\nhas ever been capable of remembering which is which for more than a few\nseconds.\n\nFurthermore, we're planning to add open answers to polls, and we might\nadd a reference from the `poll_answers` table to the\n`poll_question_answers` table to property differentiate between open\nanswers and closed answers. Having yet another thing named answer would\nbe more than what our brains can handle (we know it because we did this\nonce in a prototype).\n\nSo we're renaming `Poll::Question::Answer` to `Poll::Question::Option`.\nHopefully that'll make it easier to remember. The name is also (more or\nless) consistent with the `Legislation::QuestionOption` class, which is\nsimilar.\n\nWe aren't changing the table or columns names for now in order to avoid\npossible issues when upgrading (old code running with the new database\ntables/columns after running the migrations but before deployment has\nfinished, for instance). We might do it in the future.\n\nAt first I tried not to change the internationalization keys either so\nexisting translations would still be valid. However, since we have to\nchange the keys in `activerecord.yml`, since it uses class names and\nwe're changing the class names, we're changing them everywhere for\nconsistency.\n\nNote that it isn't clear whether we should use `option` or\n`question_option` in some cases. In order to keep things simple, we're\nusing `option` where we were using `answer` and `question_option` where\nwe were using `question_answer`.","shortMessageHtmlLink":"Rename Poll::Question::Answer to Poll::Question::Option"}},{"before":"33d7407d8bda980c02f0c3cf728043230f7c9057","after":"5724d860900fedbad9115d5ae80fe3232ec4d9d1","ref":"refs/heads/linters_in_github_actions","pushedAt":"2024-05-17T20:28:51.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Run every linter separately in Github Actions\n\nThe main reason for this change is that Pronto doesn't run in pull\nrequests opened by external contributors, and we haven't found how to\nfix this issue.\n\nAnother reason is that Pronto only detects issues in the lines where the\nchanges are done, but sometimes we introduce issues related to other\nlines and those aren't detected by Pronto. Also, when adding or changing\nRubocop rules, or when we update Rubocop, Pronto doesn't check whether\nthose rules are applied in every Ruby and ERB file, and we sometimes\nforget to do so (particularly in ERB files).\n\nSo, from now, the linters will check all the code in every pull request.","shortMessageHtmlLink":"Run every linter separately in Github Actions"}},{"before":"35511870738613434af5323ac6bd7a50a049b43e","after":"301ecb171aa2981d740bd92730ce4b9e8524924f","ref":"refs/heads/budgets_stats_cache","pushedAt":"2024-05-17T18:12:19.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Generate stats on every request without caching them\n\nIn commit e51e03446, we started using the same code to show stats in the\npublic area and in the admin area. However, in doing so we introduced a\nbug, since stats in the public area are only shown after a certain part\nof the process has finished, meaning the stats appearing on the page\nnever change (in theory), so it's perfectly fine to cache them. However,\nin the admin area stats can be accessed while the process is still\nongoing, so caching the stats will lead to the wrong results being\ndisplayed.\n\nWe've thought about expiring the cache when new supports or ballot lines\nare added; however, that means the methods calculating the stats for the\nsupporting phase would expire when supports are added/removed but the\nmethods calculating the stats for the voting phase would expire when\nballot lines are added/removed. It gets even more complex because the\n`headings` method calculates stats for both the supporting and the\nvoting phases.\n\nBut, since now we're using a temporary table to calculate the stats,\ngenerating them might take between 1 and 2 seconds even in processes\nwith a hundred thousand participants, meaning we can disable the cache\nand generate the stats on every request instead. It might not scale so\nwell when there are millions of participants; we might re-enable the\ncache or find a different way to optimize the stats calculations if we\never get to that point.\n\nNote that, since we're only using the temporary table inside the\n`generate` method, we need to cache the results obtained inside this\nmethod so they're available elsewhere. We're using instance variables\nfor this purpose. This means the code doesn't improve much with this\nchange, but at least we don't have to worry about when we should expire\nthe cache.\n\nSince loading stats in the admin section is fast even without the cache\nbecause they only load very basic statistics, we're not even generating\nthem first in this case, so everything works the same way it did before\ncommit e51e03446.\n\nCo-authored-by: Javi Martín ","shortMessageHtmlLink":"Generate stats on every request without caching them"}},{"before":"2f52530893e3c189343e3f55f8c7776c0ba54350","after":"ba6c18663d91e0878782a7c7739d30b30560be86","ref":"refs/heads/remove_budgets_admin_stats_cache","pushedAt":"2024-05-17T18:11:41.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"javierm","name":"Javi Martín","path":"/javierm","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35156?s=80&v=4"},"commit":{"message":"Don't use the cache in admin budget stats\n\nIn commit e51e03446, we started using the same code to show stats in the\npublic area and in the admin area. However, in doing so we introduced a\nbug, since stats in the public area are only shown after a certain part\nof the process has finished, meaning the stats appearing on the page\nnever change (in theory), so it's perfectly fine to cache them. However,\nin the admin area stats can be accessed while the process is still\nongoing, so caching the stats will lead to the wrong results being\ndisplayed.\n\nWe've thought about expiring the cache when new supports or ballot lines\nare added; however, that means the methods calculating the stats for the\nsupporting phase would expire when supports are added/removed but the\nmethods calculating the stats for the voting phase would expire when\nballot lines are added/removed. It gets even more complex because the\n`headings` method calculates stats for both the supporting and the\nvoting phases.\n\nSo, since loading stats in the admin section is fast even without the\ncache because they only load very basic statistics, we're taking the\nsimple approach of disabling the cache in this case, so everything works\nthe same way it did before commit e51e03446.\n\nCo-authored-by: Javi Martín ","shortMessageHtmlLink":"Don't use the cache in admin budget stats"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEUYvZFQA","startCursor":null,"endCursor":null}},"title":"Activity · consuldemocracy/consuldemocracy"}