decidim-core/lib/decidim/participatory_space/has_members.rb:43

• The method private_space? no longer exists after the migration to access_mode. This should be changed to return true if open? or return true unless restricted?.

          return true unless private_space?

decidim-participatory_processes/db/migrate/20260111120010_add_access_mode_to_participatory_processes.rb (1)

3-10: Missing data migration for existing records.

The migration adds the column but doesn't transform existing private_space and is_transparent values to the new access_mode enum. Per the PR objectives, the mapping should be:

Old state	New access_mode
private_space: false, is_transparent: false	0 (open)
private_space: false, is_transparent: true	1 (transparent)
private_space: true	2 (restricted)

Without data migration, all existing records default to 0 (open), potentially exposing previously restricted processes.

Proposed fix with data migration

 class AddAccessModeToParticipatoryProcesses < ActiveRecord::Migration[6.1]
   def up
     add_column :decidim_participatory_processes, :access_mode, :integer, null: false, default: 0
+
+    execute <<-SQL.squish
+      UPDATE decidim_participatory_processes
+      SET access_mode = CASE
+        WHEN private_space = true THEN 2
+        WHEN is_transparent = true THEN 1
+        ELSE 0
+      END
+    SQL
   end

   def down
     remove_column :decidim_participatory_processes, :access_mode
   end
 end

Verify if a separate data migration exists to handle this transformation:

#!/bin/bash
# Search for data migration handling access_mode transformation for participatory processes
rg -n -C5 'UPDATE.*decidim_participatory_processes.*access_mode|private_space.*access_mode' --type ruby

decidim-admin/app/jobs/decidim/admin/participatory_space/destroy_members_follows_job.rb (1)

10-12: Method name missing question mark on line 10.

The respond_to?(:transparent) check is inconsistent with the actual method call space.transparent? on line 12. This should be respond_to?(:transparent?).

Suggested fix

-          return unless space.respond_to?(:restricted?) || space.respond_to?(:transparent)
+          return unless space.respond_to?(:restricted?) || space.respond_to?(:transparent?)

decidim-admin/app/commands/decidim/admin/participatory_space/destroy_member.rb (1)

21-21: Method name missing question mark.

The respond_to?(:transparent) check should be respond_to?(:transparent?) to match the actual method being called.

Suggested fix

-          return if resource.participatory_space.respond_to?(:transparent) && resource.participatory_space.transparent?
+          return if resource.participatory_space.respond_to?(:transparent?) && resource.participatory_space.transparent?

decidim-assemblies/db/migrate/20260111120000_add_access_mode_to_assemblies.rb (1)

3-10: Missing data migration to backfill existing records.

The migration adds the column with default: 0 (open), but existing assemblies with private_space: true will incorrectly be set to open access instead of restricted/transparent. This could inadvertently expose previously private content.

Add SQL statements to map existing private_space and is_transparent values to the correct access_mode:

• access_mode: 0 (open) when private_space = false
• access_mode: 1 (transparent) when private_space = true AND is_transparent = true
• access_mode: 2 (restricted) when private_space = true AND is_transparent = false

decidim-assemblies/app/models/decidim/assembly.rb (1)

100-103: Fix public_spaces scope chaining to avoid empty results.

open.transparent.published on Line 102 composes scopes with AND, which yields no records because a row can’t be both open and transparent. Use an OR or a single IN filter instead.

🐛 Proposed fix

-      open.transparent.published
+      where(access_mode: %i[open transparent]).published

decidim-participatory_processes/app/views/decidim/participatory_processes/admin/participatory_processes/_form.html.erb (1)

174-191: LGTM! All three access modes are now implemented.

The radio button group correctly includes all three access options (open, transparent, restricted), which aligns with the PR objectives and addresses the previous review feedback about the missing transparent option.

decidim-participatory_processes/app/views/decidim/participatory_processes/admin/participatory_processes/_process_row.html.erb (1)

17-24: LGTM! Transparent access mode is now handled.

The view correctly implements all three access mode states, addressing the previous review feedback about the missing transparent handling.

decidim-participatory_processes/lib/decidim/participatory_processes/test/factories.rb (1)

60-66: New traits look correct, but consider updating the legacy :private trait for consistency.

The :transparent and :restricted traits correctly set the new access_mode attribute. However, the existing :private trait (lines 56-58) still sets private_space { true } using the old approach. Per the PR objectives, private_space: true maps to access_mode: :restricted.

Consider updating the :private trait to use the new access mode or deprecating it in favor of :restricted to avoid confusion in tests:

♻️ Suggested update to align `:private` trait

     trait :private do
-      private_space { true }
+      access_mode { :restricted }
     end

Alternatively, if backward compatibility is needed, deprecate :private and direct users to :restricted.

decidim-assemblies/db/migrate/20190215093700_reset_negative_children_count_counters.rb (1)

9-10: Prefer batched iteration to avoid loading all ids.

pluck loads all matching IDs into memory. Using find_each keeps this safe for large tables.

♻️ Proposed refactor

-    ids = Assembly.unscoped.where("children_count < 0").pluck(:id)
-    ids.each { |id| Assembly.unscoped.reset_counters(id, :children_count) }
+    Assembly.unscoped.where("children_count < 0").find_each do |assembly|
+      Assembly.unscoped.reset_counters(assembly.id, :children_count)
+    end

decidim-participatory_processes/db/migrate/20210310120750_add_followable_counter_cache_to_participatory_processes.rb (1)

4-6: Prefer ActiveRecord::Base for migration-local models.

This keeps migrations insulated from app-level concerns that might be mixed into ApplicationRecord.

♻️ Suggested change

-  class ParticipatoryProcess < ApplicationRecord
+  class ParticipatoryProcess < ActiveRecord::Base
     self.table_name = :decidim_participatory_processes
   end

decidim-admin/app/commands/decidim/admin/participatory_space/destroy_member.rb (1)

23-24: Comment is misleading.

The comment says "restricted or transparent spaces" but the code logic returns early if transparent (skipping the job), so it actually only runs for restricted non-transparent spaces.

Suggested fix

-          # When member is destroyed, a hook to destroy the follows of user on restricted or transparent spaces
+          # When member is destroyed, a hook to destroy the follows of user on restricted (non-transparent) spaces
           # and the follows of their children

decidim-participatory_processes/app/controllers/concerns/decidim/participatory_processes/admin/filterable.rb (1)

43-48: Duplicate private keyword and potential filter value mismatch.

1. Line 44 declares private again, but line 14 already established a private section.
2. The access_modes method returns the full hash (ACCESS_MODES), but scope_search_multi in the model is defined with ACCESS_MODES.keys (symbols). Depending on how the filter UI consumes this, you may want to return .keys for consistency.

♻️ Suggested fix

          def translated_decidim_participatory_process_group_id_eq(id)
            translated_attribute(Decidim::ParticipatoryProcessGroup.find(id).title)
          end

-          private
-
          def access_modes
-            ParticipatoryProcess::ACCESS_MODES
+            ParticipatoryProcess::ACCESS_MODES.keys
          end

decidim-participatory_processes/app/forms/decidim/participatory_processes/admin/participatory_process_form.rb (1)

34-36: Consider adding validation for access_mode.

The access_mode attribute is declared without validation. While Rails enums will raise an ArgumentError for invalid values, adding form-level validation provides better user feedback and prevents invalid submissions from reaching the model.

♻️ Suggested validation

        attribute :access_mode, String
        attribute :has_members, Boolean
        attribute :promoted, Boolean
+
+       validates :access_mode, inclusion: { in: Decidim::ParticipatoryProcess::ACCESS_MODES.keys.map(&:to_s) }

decidim-assemblies/app/views/decidim/assemblies/admin/assemblies/_form.html.erb (1)

208-225: Consider wrapping the radio group in a <fieldset> for semantics.

Line 209 already uses a legend; grouping these inputs with a fieldset improves accessibility semantics.

♻️ Suggested markup tweak

-      <div class="row column" id="access_mode">
-        <legend>
-          <%= t("access.label", scope: "decidim.assemblies.admin.assemblies.form") %>
-        </legend>
-        <div class="radio-group">
+      <div class="row column" id="access_mode">
+        <fieldset class="radio-group">
+          <legend>
+            <%= t("access.label", scope: "decidim.assemblies.admin.assemblies.form") %>
+          </legend>
           <%= label_tag nil, class: "form__wrapper-checkbox-label" do %>
             <%= form.radio_button :access_mode, :open %>
             <span><%= t("access.options.open", scope: "decidim.assemblies.admin.assemblies.form") %></span>
           <% end %>
           <%= label_tag nil, class: "form__wrapper-checkbox-label" do %>
             <%= form.radio_button :access_mode, :transparent %>
             <%= t("access.options.transparent", scope: "decidim.assemblies.admin.assemblies.form") %>
           <% end %>
           <%= label_tag nil, class: "form__wrapper-checkbox-label" do %>
             <%= form.radio_button :access_mode, :restricted %>
             <%= t("access.options.restricted", scope: "decidim.assemblies.admin.assemblies.form") %>
           <% end %>
-        </div>
+        </fieldset>
       </div>

decidim-assemblies/spec/serializers/decidim/assemblies/assembly_serializer_spec.rb (1)

35-35: LGTM!

The test correctly verifies that access_mode is included in the serialized output.

Consider adding additional test cases verifying serialization for each access mode variant (open, transparent, restricted) to ensure all enum values serialize correctly.

decidim-assemblies/app/views/decidim/assemblies/assemblies/show.html.erb (1)

19-22: LGTM!

The condition correctly uses restricted? to show the alert only when the assembly is restricted (members-only visibility), which matches the PR mapping where Restricted = only members can see and participate.

Consider updating the translation key from "private_space" to something like "restricted_space" for consistency with the new access mode terminology. This would help align user-facing text with the new "Restricted" concept.

decidim-assemblies/spec/forms/assembly_form_spec.rb (1)

86-87: Consider asserting the access_mode default/validity in this spec.

Now that access_mode drives visibility, a small expectation (e.g., defaulting to "open" or rejecting invalid values) would guard regressions.

Also applies to: 151-152

decidim-assemblies/spec/system/assemblies_spec.rb (2)

259-273: Align test naming with the new access_mode terminology.

The context and variable names still use “private/transparent”, which no longer matches the access_mode model. Consider renaming for clarity and consistency.

♻️ Suggested rename

-context "when the assembly has children private and transparent assemblies and related assemblies block is active" do
-  let!(:private_transparent_child_assembly) { create(:assembly, organization:, parent: assembly, access_mode: :transparent) }
-  let!(:private_transparent_unpublished_child_assembly) { create(:assembly, :unpublished, organization:, parent: assembly, access_mode: :transparent) }
+context "when the assembly has children transparent assemblies and related assemblies block is active" do
+  let!(:transparent_child_assembly) { create(:assembly, organization:, parent: assembly, access_mode: :transparent) }
+  let!(:transparent_unpublished_child_assembly) { create(:assembly, :unpublished, organization:, parent: assembly, access_mode: :transparent) }
@@
-    expect(page).to have_link translated(private_transparent_child_assembly.title)
-    expect(page).to have_no_link translated(private_transparent_unpublished_child_assembly.title)
+    expect(page).to have_link translated(transparent_child_assembly.title)
+    expect(page).to have_no_link translated(transparent_unpublished_child_assembly.title)

---

276-287: Rename “private and not transparent” to “restricted” for clarity.

This block still uses the old model naming. Updating it to “restricted” will keep test intent aligned with the access_mode enum.

♻️ Suggested rename

-context "when the assembly has children private and not transparent assemblies" do
-  let!(:private_child_assembly) { create(:assembly, organization:, parent: assembly, access_mode: :restricted) }
-  let!(:private_unpublished_child_assembly) { create(:assembly, :unpublished, organization:, parent: assembly, access_mode: :restricted) }
+context "when the assembly has children restricted assemblies" do
+  let!(:restricted_child_assembly) { create(:assembly, organization:, parent: assembly, access_mode: :restricted) }
+  let!(:restricted_unpublished_child_assembly) { create(:assembly, :unpublished, organization:, parent: assembly, access_mode: :restricted) }

decidim-api/lib/decidim/api/test/component_context.rb (1)

128-138: Duplicate test context detected.

There are two identical "when user is member" context blocks at lines 128-132 and 134-138. This appears to be a copy-paste duplication that adds redundant test coverage.

♻️ Proposed fix

       context "when user is member" do
         let!(:current_user) { create(:user, :confirmed, organization: current_organization) }
         let!(:member) { create(:member, user: current_user, participatory_space: participatory_process) }
         it_behaves_like "graphQL visible resource"
       end

-      context "when user is member" do
-        let!(:current_user) { create(:user, :confirmed, organization: current_organization) }
-        let!(:member) { create(:member, user: current_user, participatory_space: participatory_process) }
-        it_behaves_like "graphQL visible resource"
-      end
-
       context "when user is normal user" do

decidim-participatory_processes/spec/types/integration_schema_spec.rb (1)

274-329: Add a transparent process to actually exercise the new access mode.

The context name mentions transparent spaces, but none are created. This misses coverage for the “visible but members-only participation” path.

♻️ Suggested test adjustment

       let!(:participatory_process2) { create(:participatory_process, organization: current_organization) }
       let!(:participatory_process3) { create(:participatory_process, organization: current_organization) }
+      let!(:transparent_process) { create(:participatory_process, :transparent, organization: current_organization) }
       let!(:restricted_process) { create(:participatory_process, :restricted, organization: current_organization) }

@@
         expect(response["participatoryProcesses"]).to include(
           { "id" => participatory_process.id.to_s },
           { "id" => participatory_process2.id.to_s },
-          { "id" => participatory_process3.id.to_s }
+          { "id" => participatory_process3.id.to_s },
+          { "id" => transparent_process.id.to_s }
         )
@@
         expect(response["participatoryProcesses"]).to include(
           { "id" => participatory_process.id.to_s },
           { "id" => participatory_process2.id.to_s },
-          { "id" => participatory_process3.id.to_s }
+          { "id" => participatory_process3.id.to_s },
+          { "id" => transparent_process.id.to_s }
         )
@@
         expect(response["participatoryProcesses"]).to include(
           { "id" => participatory_process.id.to_s },
           { "id" => participatory_process2.id.to_s },
           { "id" => participatory_process3.id.to_s },
+          { "id" => transparent_process.id.to_s },
           { "id" => restricted_process.id.to_s }
         )
@@
         expect(response["participatoryProcesses"]).to include(
           { "id" => participatory_process.id.to_s },
           { "id" => participatory_process2.id.to_s },
           { "id" => participatory_process3.id.to_s },
+          { "id" => transparent_process.id.to_s },
           { "id" => restricted_process.id.to_s }
         )

decidim-participatory_processes/lib/decidim/participatory_processes/test/factories.rb (1)

55-61: Consider adding an :open trait for consistency with the three-access-mode model.

The ParticipatoryProcess model defines three access modes (open, transparent, restricted) via the enum ACCESS_MODES = { open: 0, transparent: 1, restricted: 2 }, with open as the default. The factory currently includes only :transparent and :restricted traits. Adding an explicit :open trait would improve test clarity and make the access mode explicit across all three cases.

Suggested addition

+    trait :open do
+      access_mode { :open }
+    end
+
     trait :transparent do
       access_mode { :transparent }
     end