- `#update_ancestors` was never called with multiple work packages at
once. So now it accepts only one work package.
- `#update_ancestors_all_attributes` was called only twice and accepts
multiple work packages. To differentiate it from `#update_ancestors`,
prefix it with `multi_`.
- remove the need to have both `#multi_update_ancestors` and
`#multi_update_ancestors_all_attributes` as it's always called with
all attributes, so keep only `#multi_update_ancestors` and make
`#update_ancestors` use all attributes if no changed attributes are
provided.
- then clean up places where it was used.
https://community.openproject.org/wp/68560
Previous fix of the same issue was incorrect, because
`UpdateAncestorsService` was no longer saving the work package if the
changes were done outside of the service. Sadly, automatically generated
subjects are updated outside of the service and rely on
`UpdateAncestorsService` to be saved. That's a code smell which should
be fixed in a future refactoring.
An integration test was added to ensure the automatically generated
subject is saved correctly, the fix was reverted, and another fix was
found.
Now the fix is to consider the changes from both the update service and
the `UpdateAncestorsService` when calling the `SetScheduleService`.
Favorite is the correct term in the context of expressing a preference
for a particular project / other OpenProject domain object.
Updates `ActsAsFavorable` to `ActsAsFavoritable`, as well as filenames,
identifiers and strings to:
favored => favorited
favorable => favoritable
favoring => favoriting
`#valid?` will run all validations for a given record (unless a specific
context is specified). This patch attempts to optimize
`#valid_attribute?` to run only the validations applicable to the given
attribute.
AnyFixture will create once instance of a factory for reuse in a number of specs.
This will work fine until we require a clean slate for a specific example.
As we have numerous tests that test like the database is empty,
we get a number of disadvantages:
- After an example with `with_clean_fixture` metadata, the fixture will only be regenerated
after the next example that uses it. This means the order of execution will change
the number of objects in the DB.
- The more `with_clean_fixture` we have, the smaller the performance advantage of AnyFixture will
result in.
- You cannot use an AnyFixture in a spec that needs a clean slate. This should be obvious but was overlooked
by myself.
Uses FactoryBot to keep and maintain specific records in a special transaction that does not get removed after each spec.
They automatically are created whenever first hitting them.
This makes an excellent time saver for items that are commonly used, such as an admin user account
* Hack spike to show D&D use case
[ci skip]
* Add ordered work packages
* Save order on existing work packages
* Boards WIP
* CDK drag
* Add dragula handler
[ci skip]
* Add filter to return all manual sorted work packages
* Print icon on hover
* Boards routing and list components
* Better loading indicator on list with streaming result
[ci skip]
* Add new board and list buttons
[ci skip]
* Post new query
[ci skip]
* Added creation of new board lists with persisted queries
[ci skip]
* Render placeholder row in empty queries
[ci skip]
* Push boards on grid
* Use base class in scope
[ci skip]
* Extend api for options
* Hack spike to show D&D use case
[ci skip]
* Add ordered work packages
* Save order on existing work packages
* Boards WIP
* CDK drag
* Add dragula handler
[ci skip]
* Add filter to return all manual sorted work packages
* Print icon on hover
* Boards routing and list components
* Better loading indicator on list with streaming result
[ci skip]
* Add new board and list buttons
[ci skip]
* Post new query
[ci skip]
* Added creation of new board lists with persisted queries
[ci skip]
* Render placeholder row in empty queries
[ci skip]
* Save queries in grids
[ci skip]
* Renaming queries
[ci skip]
* Add existing work packages to board
[ci skip]
* Introduce card view component for work packages
* Extend grids to allow project scope for boards (#7025)
Extends the grid backend to also be able to handle boards. In particular, it adds the ability of boards to be attached to projects and changes the page property of grids to a scope property that better describes that more than one board can belong to the same scope (e.g. /projects/:project_id/boards).
For a fully featured board, though, widgets need to be able to store options, so that they can store queries. Those widgets might also need to have custom processing and validation. That part has not been implemented.
* introduce project association for boards
* have dedicated grid registration classes
* update and create form for board grids
* extract defaults into grid registration
[ci skip]
* Add drag and drop to card view
[ci skip]
* Add options to grid
* Fix option migration name
* Renaming boards
[ci skip]
* Frontend deletion of boards
* Avoid map on NodeList which doesnt exist
[ci skip]
* Add inline create to boards
[ci skip]
* Smaller create button
[ci skip]
* Add navigation for boards
* Make inner grid same height
* Replace index page with table
* Workaround for widget registration
[ci skip]
* Fixed height for cards and tables
[ci skip]
* Implement escape as cancel d&d action
[ci skip]
* Fix and extend grid specs for name and options
* Extend board specs for required name
* Fix migration for MySQL references
https://stackoverflow.com/a/45825566/420614
* Make board list extend from widget
Since we cannot configure widgets yet, it's not yet possible to use a
board-list widget anywhere.
* Fix specs
* Fix escape listener removal
[ci skip]
* Fix renamed to_path in relation spec
[ci skip]
* Allow deletion of grids for boards
* Avoid reloading resource multiple times with replays
* Frontend synchronization on deletion
[ci skip]
* Delete through table
* Use work packages board path
* Use work packages board path
* Fix augmented columns breaking re-rendering
* Fix duplicated permission with forums
* Strengthen tab switch in specs
* Add hidden flag for project-context queries
Allows the API to create a hidden query that will not be rendered to the
user even if it is within a project context.
* private queries
* Add hidden flag for project-context queries
Allows the API to create a hidden query that will not be rendered to the
user even if it is within a project context.
* Move boards below work packages
* Add Board configuration modal
* Fix reloading with onPush
* Saving / Switching of display mode
[ci skip]
* Extract wp-query-selectable-title into common component
* Fix renaming of board-list
* Fix auto-hide notifications in boards
* Add permissions to seeders
* Reorder lists in board
* Linting
* Remove default gravatar from settings
* Show assignees avatar in the card view of WPs
* Fix specs
* Add missing method
* Fix timeline icon
* Use URL as input to be able to show avatars for groups, too
* Fix test
* Add further specs
* Use correct data attribute to avoid unnecessary data base calls
* Add further specs
* Deletion of board lists
* Pass permission via gon to decide whether we can create boards
* Fix rename spec
* Cherry-pick of 7873d59 and 30abc7f
Oliver Günther