Add Submit button and statusbar to all detail forms and use Datetime.now() for membership start_date#21
Conversation
…etail forms Add header with Submit for Approval / Resubmit buttons and approval state statusbar to all CR detail form views, enabling users to submit directly from the detail form.
Summary of ChangesHello @gonzalesedwin1123, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the user experience for managing change requests by embedding key approval workflow actions and status indicators directly within the detail forms. Users can now submit or resubmit change requests for approval and view their current status at a glance, streamlining the overall process and reducing the need for extra navigation. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
fields.Date.today() produces midnight UTC, which displays incorrectly in non-UTC timezones. The membership start_date field is a Datetime, so use fields.Datetime.now() to record the actual time the member was added.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a consistent header with submission buttons and a status bar to all change request detail forms. This is a great usability improvement, as it allows users to submit or resubmit a change request directly from the detail view without navigating back to the main CR form. The XML formatting cleanups also improve code readability.
I have one suggestion regarding the implementation. The new <header> block is duplicated across 11 different view files. While this works, it could pose a maintainability challenge in the future. I've left a comment on one of the files with a suggestion to use a QWeb template to centralize this common UI component. This would ensure that any future changes to the header only need to be made in a single location.
| <header> | ||
| <button | ||
| name="action_submit_for_approval" | ||
| string="Submit for Approval" | ||
| type="object" | ||
| class="btn-primary" | ||
| invisible="approval_state != 'draft'" | ||
| /> | ||
| <button | ||
| name="action_submit_for_approval" | ||
| string="Resubmit for Review" | ||
| type="object" | ||
| class="btn-primary" | ||
| invisible="approval_state != 'revision'" | ||
| /> | ||
| <field | ||
| name="approval_state" | ||
| widget="statusbar" | ||
| statusbar_visible="draft,pending,approved,applied" | ||
| /> | ||
| </header> |
There was a problem hiding this comment.
To improve maintainability and reduce code duplication, consider extracting this common header into a reusable QWeb template. This same header is added to 11 different form views in this PR. By using a template, any future changes to the submission buttons or status bar will only need to be made in one place.
You could define the template in a new or existing XML file (e.g., inside a <templates> tag):
<templates>
<t t-name="spp_change_request_v2.cr_detail_form_header">
<header>
<button
name="action_submit_for_approval"
string="Submit for Approval"
type="object"
class="btn-primary"
invisible="approval_state != 'draft'"
/>
<button
name="action_submit_for_approval"
string="Resubmit for Review"
type="object"
class="btn-primary"
invisible="approval_state != 'revision'"
/>
<field
name="approval_state"
widget="statusbar"
statusbar_visible="draft,pending,approved,applied"
/>
</header>
</t>
</templates>Then, you can replace the <header> block in this file and all other similar detail forms with a single line, as suggested below.
<t t-call="spp_change_request_v2.cr_detail_form_header"/>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| name="approval_state" | ||
| widget="statusbar" | ||
| statusbar_visible="draft,pending,approved,applied" | ||
| /> |
There was a problem hiding this comment.
Statusbar references non-existent "applied" state in approval_state
Low Severity
The statusbar uses approval_state field with statusbar_visible="draft,pending,approved,applied", but approval_state (from spp.approval.mixin) only has values: draft, pending, revision, approved, rejected. The value applied doesn't exist in this field. The main change request view correctly uses display_state which includes applied. This inconsistency means detail forms will never display the "Completed" status in their statusbar, even when the change request has been applied.
Additional Locations (2)
gonzalesedwin1123
changed the title
… All Requests list Override the default New button in the All Requests list view to open the create wizard (spp.cr.create.wizard) instead of the form view, matching the behavior of the "New Request" menu item. Follows the same ListController patch pattern used by spp_programs.
| t-if="!editedRecord and activeActions.create and props.showButtons and canCreateChangeRequest" | ||
| type="button" | ||
| class="btn btn-primary o_list_button_add_cr" | ||
| accesskey="c" |
There was a problem hiding this comment.
Inconsistent keyboard shortcut attribute usage
Low Severity
The "New Request" button uses accesskey="c" while the fallback "New" button on line 22 and all other buttons in the codebase use data-hotkey="c". The accesskey attribute is a native HTML attribute with browser-specific behavior, whereas data-hotkey is Odoo's unified hotkey system that integrates with the framework's keyboard shortcuts dialog and provides consistent cross-platform behavior. This inconsistency means the shortcut will behave differently and won't appear in Odoo's keyboard shortcuts helper.
|
|
||
| <t t-inherit="web.FormView" t-inherit-mode="extension"> | ||
| <xpath expr="//button[hasclass('o_form_button_create')]" position="attributes"> | ||
| <attribute name="t-if">model.root.resModel != 'spp.change.request'</attribute> |
There was a problem hiding this comment.
FormView create button loses permission check on t-if override
Medium Severity
The FormView modification uses position="attributes" to set a new t-if condition on the create button, which completely replaces any existing t-if condition. The standard Odoo FormView create button has conditions like activeActions.create to check permissions. The new condition model.root.resModel != 'spp.change.request' only checks the model type, losing the permission checks. This causes the create button to appear in forms even when the user lacks create permission. The ListView modification correctly preserves activeActions.create (line 19), but the FormView modification does not.
…tion and missing CR types
- Remove deleted default_types.xml and stale manifest comment, since CR
types are now provided by spp_cr_types_base/spp_cr_types_advanced
- Add get_or_create_cr_type() and get_or_create_membership_kind() test
helpers in common.py so tests create required data dynamically instead
of relying on env.ref() lookups that fail without type modules installed
- Add CRTestCase base class with shared setup for registrants and CR creation
- Fix get_or_create_membership_kind() to pass is_local=True when creating
codes on system vocabularies (required by spp_vocabulary protection)
- Fix AttributeError in add_member and transfer_member preview strategies:
spp.vocabulary.code uses 'display' field, not 'name'
- Remove redundant skipTest guards across all strategy test files
- Fix JS/XML formatting (prettier)
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| /> | ||
| </t> | ||
| </t> | ||
| </xpath> |
There was a problem hiding this comment.
Template extensions overwrite existing program create button
High Severity
The new create_change_request_template.xml extends web.ListView using position="replace" on the same xpath (//Layout/t[@t-set-slot='control-panel-create-button']) that spp_programs/static/src/xml/create_program_template.xml already targets. When both modules are installed, the second extension applied completely overwrites the first — causing one module's custom create button (either "Create Program" or "New Request") to silently fall through to the default "New" button. The same conflict occurs for the web.FormView extension, where both set t-if on the same o_form_button_create button, so only one model's create button gets properly hidden.
Additional Locations (1)
2 participants
Add header with Submit for Approval / Resubmit buttons and approval state statusbar to all CR detail form views, enabling users to submit directly from the detail form.
Use Datetime.now() for membership start_date fields.Date.today() produces midnight UTC, which displays incorrectly in non-UTC timezones. The membership start_date field is a Datetime, so use fields.Datetime.now() to record the actual time the member was added.
Override the default New button in the All Requests list view to open the create wizard (spp.cr.create.wizard) instead of the form view, matching the behavior of the "New Request" menu item.
Note
Low Risk
Mostly formatting-only doc updates plus a small UI patch that changes how new
spp.change.requestrecords are created; risk is limited to change-request list/form create behavior.Overview
This PR is largely documentation/packaging cleanup: it reflows many module
README.rstfiles and generatedstatic/description/index.htmlpages (whitespace, tables, line wrapping) without changing functional behavior.On the tooling side, it updates
eslint.config.cjsto lint JS under**/static/src/**/*.js.For
spp_change_request_v2, it drops the bundleddata/default_types.xmldefaults and adds backend assets (static/src/js/create_change_request.js,static/src/xml/create_change_request_template.xml) that patch the list/form views so the “New” action forspp.change.requestopens the create wizard (action_cr_create_wizard) instead of the standard record create flow (gated by group checks).Written by Cursor Bugbot for commit 9e7eb4b. This will update automatically on new commits. Configure here.