-
-
Notifications
You must be signed in to change notification settings - Fork 393
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
Comments
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. |
@decidim/product I have some doubts about this. Here's what I understand it should look like:
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. |
@mrcasals about your questions:
Correct!
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. |
We talked this offline and agreed to this:
@carolromero can you confirm, please? 😄 |
Perfectly summarized, thanks @mrcasals! |
@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? |
I think that'd be better than the current proposal of having group buttons, as:
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 yes, we might work with that :-) |
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: |
@htmlboy pinging for this! What do you think about this proposal? It will be great to have it ready for next sprint beginning next Wednesday. |
@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 😄 |
Hi, this is my proposal of Edit button + More actions, following de "More" pattern in the main navigation: This is an WIP in 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? |
@carolromero I'm currently working on showing draft initiatives. The thing is |
@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. Just last thing, as requested by @htmlboy:
Thank you 😄 |
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.
* 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>
* 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>
* 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>
* 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>
* 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>
* 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>
* 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>
* 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>
…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>
…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>
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:
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:
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:
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
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).
Initiative page created pending technical validation
This is the page with the actions to be taken when an initiative is not published.
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.
Does this issue could impact on users private data?
No
Acceptance criteria
The text was updated successfully, but these errors were encountered: