Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EPIC: Management of the initiatives by the promoters from the front-end #5736

Closed
11 tasks done
carolromero opened this issue Feb 13, 2020 · 73 comments · Fixed by #6790
Closed
11 tasks done

EPIC: Management of the initiatives by the promoters from the front-end #5736

carolromero opened this issue Feb 13, 2020 · 73 comments · Fixed by #6790
Assignees
Labels

Comments

@carolromero
Copy link
Member

carolromero commented Feb 13, 2020

ref: PP016

User story

Is your feature request related to a problem? Please describe.

As an administrator of Decidim, I'm worried that users who have to promote an Initiative can access the admin panel (although limited to only their initiatives). I'm worried about security and usability reasons:

  • Security:
    • our backend forms are not that well sanitized as our frontend forms
    • if there's an issue with our Authorization strategy a user could potentially access to all the administrator
  • Usability: as a user is weird to have access to the administrator panel

Describe the solution you'd like
To migrate these forms from the backend admin panel to the frontend.

The actions that need to be available on frontend are:

  • View Initiatives
  • Edit Initiative
  • Accept promotor committee members
  • Print form application
  • Manage Attachments
  • Send to Technical Validation

For contractual and time constraints we're not handling some actions, so it'd still be accessible the admin panel backend, but the logic will change, as the participant would access the backend once an admin has technically validated her initiative. The actions we will not support for the moment are:

  • Manage Meetings
  • Manage Pages

Describe alternatives you've considered
It's difficult especially for usability reasons, as this couldn't be solved in other ways.

The lists of the initiatives that I've created should be listed on the "My initiatives" filter on the Initiatives list.

If we didn't have the time constraints, it'd be awesome to have all the actions so no participant can access the admin panel.

Additional context

🎨 Frontend

Last step of Initiative creation wizard

This is the last step of the wizard to create an initiative. We have to modify the text that until now said that the author must access the administration panel to manage it. In this mockup there are the texts to be displayed from now on

imatge

Initiative edit form

If the author clicks on "Edit my initiative" the editing form of the initiative is displayed with all the actions integrated in it, except the button "Send to technical validation". You can see that we have included the management of the attachments, the promotion committee and the action of printing.

If the initiative doesn't require a promotion committee or does not require attachments, they will not be shown on the form (these options are configurable settings according to the type of initiative).

imatge

Initiative page created pending technical validation

This is the page with the actions to be taken when an initiative is not published.

imatge

Initiative page published

Once the initiative is published, there is no point in showing the action buttons because the author can no longer modify it. That's when the signature counter and comments are displayed.

imatge
Does this issue could impact on users private data?
No

Acceptance criteria

  • As an admin I can manage from the admin panel any initiative as before
  • As a promoter of an Initiative I see an updated explanation of the steps to follow in the last step of the initiative creation wizard
  • As a promoter of an Initiative I can see all my Initiatives through the filter "My initiatives", regardless of the status they're in
  • As a promoter of an Initiative I don't have access to admin panel
  • As a promoter of an Initiative I can edit the Initiative on the frontend
  • As a promoter of an Initiative I can manage (Create, Read, Update, Delete) attachments if applicable, through the edition form
  • As a promoter of an Initiative I can manage members of the promotor committee if applicable, through the edition form
  • As a promoter of an Initiative I can print the form application
  • As a promoter of an Initiative I can send to technical validation
  • As a promoter of an Initiative when I send to technical validation I see a modal confirmation of "Are you sure?"
  • As a visitor I only see open and closed initiatives
@carolromero carolromero added the contract: PAM2020 Barcelona City Council contract label Feb 13, 2020
@carolromero carolromero added this to Product Backlog in PAM2020 Feb 13, 2020
@stale
Copy link

stale bot commented Apr 13, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. @carolromero & @xabier feel free to chime in.

@stale stale bot added the wontfix label Apr 13, 2020
@carolromero carolromero added this to Product Backlog in Design2020 May 11, 2020
@carolromero carolromero changed the title MEGA-EPIC: Management of the initiatives by the promoters from the front-end EPIC: Management of the initiatives by the promoters from the front-end May 25, 2020
@mrcasals
Copy link
Contributor

@decidim/product I have some doubts about this. Here's what I understand it should look like:

  • The admin will have the initiative types section, only admins can handle this part
  • Initiatives section will no longer be accessible in the admin section. But there are some sections and features than can only be performed on the admin side, what should we do with those?
    • Export initiatives
    • Answer a given initiative
    • Moderate content from meetings

We could leave access to the initiative list, so admins can answer an initiative, and export them, but the problem with moderations would still exist.

How should we proceed? This affects the effort of the task.

@carolromero
Copy link
Member Author

@mrcasals about your questions:

The admin will have the initiative types section, only admins can handle this part

Correct!

Initiatives section will no longer be accessible in the admin section

Not really. The current flow to create an initiative is complex for its promoter (a participant), because there are some actions that she has to do in the frontend and in the backend.

The idea with this issue is that all the actions that a participant must do to create her initiative can be done from the frontend and she doesn't have to access the admin panel. But the admins still need access to all initiatives from the backend to manage them, not only export and reply, but also create the meetings if needed for a given initiative (this is done by the admins as well).

In case it's useful, here's a flowchart (it's a WIP) that we've made to better document all the flow.

In summary, the admins will continue to have access as before. What changes are the actions that a participant can perform, which until now were done in the backend.

@mrcasals
Copy link
Contributor

We talked this offline and agreed to this:

  • All features in the admin dashboard will be left untouched, none will be added or removed
  • Initiative creators will not be able to access the admin dashboard
  • These features need to be copied/ported to the public area, only accessible by initiative creators:
    • Edit my initiative
    • Print
    • Manage committee members
    • Manage attachments
    • Send initiative to Technical Validation

@carolromero can you confirm, please? 😄

@carolromero
Copy link
Member Author

Perfectly summarized, thanks @mrcasals!

@htmlboy
Copy link
Contributor

htmlboy commented Jul 22, 2020

@carolromero hi, @eva-sl mentioned this issue required some design validation.

Since these call to action buttons are not designed to be grouped together, I'd suggest using a drop-down menu of actions instead. So something like "Actions" that displays a menu with all these options. It also allows longer copies and adding extra options afterwards. If there's any action that is core to this interaction (i.e. it won't be published) we could reinforce this core action alone, perhaps inside the call out/alert.

Thoughts?

@andreslucena
Copy link
Member

Thoughts?

I think that'd be better than the current proposal of having group buttons, as:

  • Group buttons don't scale
  • AFAIK we don't use these kinds of buttons on other places of the app

The only issue that I see with the dropdowns buttons is that they're not defined on the frontend UI, or at least I don't remember any place where it's used on the frontend. Also, at the design app I can't find them.

@mrcasals
Copy link
Contributor

Perhaps we could reuse the component dropdown?

Closed:
image

On hover:
image

@htmlboy
Copy link
Contributor

htmlboy commented Jul 27, 2020

@mrcasals yes, we might work with that :-)

@carolromero carolromero added this to 2020 Q4 (October - December) in Roadmap Aug 5, 2020
@carolromero
Copy link
Member Author

Hi there! @htmlboy sorry I missed this comment during the holydays.

To move forward with the design, could we try the option of combining a main action button + secondary actions? The edit action will probably be used more often than the rest.

In addition to this, we will need the design of each of the actions, so it may be useful to check the existing interface in the admin panel, such as the management of the promotion committee:

image

@eva-sl
Copy link

eva-sl commented Sep 24, 2020

@htmlboy pinging for this!

What do you think about this proposal?
I also missed your message @carolromero, sorry :D

It will be great to have it ready for next sprint beginning next Wednesday.

@eva-sl
Copy link

eva-sl commented Sep 28, 2020

@carolromero just an update from our side:

@htmlboy is working on some wireframes for this EPIC. We will update it on this thread, planned to have it on this Wednesday 😄

@carolromero carolromero moved this from Product Backlog to Sprint Backlog in PAM2020 Sep 29, 2020
@marinavega marinavega self-assigned this Sep 29, 2020
@marinavega marinavega moved this from Sprint Backlog to Doing in PAM2020 Sep 29, 2020
@htmlboy
Copy link
Contributor

htmlboy commented Sep 29, 2020

Hi, this is my proposal of Edit button + More actions, following de "More" pattern in the main navigation:

Screenshot 2020-09-29 at 16 53 29

Screenshot 2020-09-29 at 16 53 44

This is an WIP in feat/initiative-management branch.

As for the actions, most of them should probably open the forms we already saw in the "wizard" creation forms, but with the proper data. Are there any additional forms not covered in these steps? Could you please post any screenshots from Admin of the missing forms/interfaces?

@marinavega
Copy link
Contributor

@carolromero I'm currently working on showing draft initiatives. The thing is draft is not a state, so I guess an initiative with a created state and without a created_at value should be equivalent to a draft? Maybe I'm missing something? 😄

@marinavega marinavega mentioned this issue Oct 2, 2020
3 tasks
@marinavega marinavega linked a pull request Oct 2, 2020 that will close this issue
3 tasks
@eva-sl
Copy link

eva-sl commented Oct 2, 2020

@decidim/product could you check the mock-up above?

It looks great @htmlboy and it covers the needs of an Edit Action as the main one + more actions.
Let us know your thoughts about this.

Just last thing, as requested by @htmlboy:

Are there any additional forms not covered in these steps? Could you please post any screenshots from Admin of the missing forms/interfaces?

Thank you 😄

@marinavega marinavega removed a link to a pull request Oct 2, 2020
3 tasks
@carolromero carolromero moved this from Ready to Technical Review in PAM2020 Nov 16, 2020
@tramuntanal tramuntanal moved this from Technical Review to Done in PAM2020 Nov 18, 2020
@carolromero carolromero moved this from Product Backlog to Technical Review in Design2020 Jan 13, 2021
@andreslucena andreslucena moved this from Technical Review to Done in Design2020 Jan 19, 2021
@carolromero carolromero moved this from 2020 Q4 (October - December) to 2021 Q1 (January - March) in Roadmap Sep 16, 2021
@carolromero carolromero moved this from 2021 Q1 (January - March) to 2020 Q4 (October - December) in Roadmap Sep 16, 2021
andreslucena added a commit that referenced this issue May 16, 2023
After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.
ahukkanen added a commit that referenced this issue Jun 7, 2023
* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix traits usages in factories calls

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Alexandru Emil Lupu <contact@alecslupu.ro>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
alecslupu added a commit that referenced this issue Jun 15, 2023
* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix traits usages in factories calls

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Alexandru Emil Lupu <contact@alecslupu.ro>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
alecslupu added a commit that referenced this issue Jun 15, 2023
* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix traits usages in factories calls

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Alexandru Emil Lupu <contact@alecslupu.ro>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
alecslupu added a commit that referenced this issue Jun 15, 2023
* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix traits usages in factories calls

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Alexandru Emil Lupu <contact@alecslupu.ro>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
alecslupu added a commit that referenced this issue Jun 15, 2023
* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix traits usages in factories calls

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Alexandru Emil Lupu <contact@alecslupu.ro>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
alecslupu added a commit that referenced this issue Jun 15, 2023
* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix traits usages in factories calls

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Alexandru Emil Lupu <contact@alecslupu.ro>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
alecslupu added a commit that referenced this issue Jun 15, 2023
* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix traits usages in factories calls

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Alexandru Emil Lupu <contact@alecslupu.ro>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
alecslupu added a commit that referenced this issue Jun 15, 2023
* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Fix traits usages in factories calls

Apply suggestions from code review

Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>

* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Alexandru Emil Lupu <contact@alecslupu.ro>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
andreslucena added a commit that referenced this issue Jun 16, 2023
…o v0.26 (#11047)

* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review



* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review



* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review



* Fix traits usages in factories calls

Apply suggestions from code review



* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Andrés Pereira de Lucena <andreslucena@users.noreply.github.com>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
andreslucena added a commit that referenced this issue Jun 16, 2023
…o v0.27 (#11042)

* Don't allow access to admin panel without ToS acceptance

* Add redirection to previous page after accepting ToS

* Use have_content instead of have_text

* Running spellcheck linters

* Fix specs

* Fix permissions on Templates when user is not admin

* Fix specs

* Fix i18n string scope from merge

* Workaround for admin ToS acceptance in Initiatives

After #5736, the initiatives' authors and commitee members should not
have access to the admin panel.

The problem is that with the change of the Terms of Service acceptance
in the admin panel this is changing, so there's still some leftovers in
the initiatives' permissions.

As I only want to focus on ToS acceptance for now, I'll skip these specs
and fix the real problem (cleaning the leftovers from #5736) on another
PR to keep this small.

* Fix typo

* Fix for possible Cookie overflow with a long list of URL params

Detected by code review

* Remove unecessary namespaces

* Fix spec

* Bring consistency to the spec messages

* "has not accepted" sounds better than "did not accepted"
* sometimes I was using "has a message" and other times "shows a
  message"
* sometimes we were using ToS and other times TOS

* Add missing specs for Templates' specs

* Remove unecessary return

Apply suggestions from code review



* Fix the stored request.path to not mess with the frontend's stored location

Apply suggestions from code review



* Fetch from stored_location_for so the session value is cleaned

Apply suggestions from code review



* Fix traits usages in factories calls

Apply suggestions from code review



* Introduce "needs admin TOS accepted" shared example

* Fix rubocop offenses

* Fix rubocop offenses

* Make the user configurable for "needs admin TOS accepted" shared example

* Fix rubocop offense

* Refactor spec to shared examples

* Add example for roles that aren't admin

---------

Co-authored-by: Andrés Pereira de Lucena <andreslucena@users.noreply.github.com>
Co-authored-by: Antti Hukkanen <antti.hukkanen@mainiotech.fi>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

8 participants