| Age | Commit message (Collapse) | Author |
|---|
|
6146 Line state update
|
|
|
|
|
|
5877 Add a condition on TableBuilderHelper::Column
|
|
|
|
|
|
|
|
scoping
|
|
|
|
scoping
|
|
|
|
scoping
|
|
|
|
|
|
scoping
|
|
|
|
scoping
|
|
belongs_to referential
|
|
|
|
This reverts commit 28db706443a912e8355e4c48488dc40c403e7f76.
Turns out we didn't need to be able to pass an arbitrary number of
arguments to the lambda after all. The URL helper objects necessary in
addition to the first argument to the lambda can be retrieved from the
view context directly instead of passing them into the block as
parameters (which would actually make things more difficult, because the
block is called in the `TableBuilderHelper`, thus outside the scope of
the view).
|
|
This enables us to pass multiple objects into the lambda, so that we can
for example build a URL using a Rails helper using multiple objects.
Example:
column.link_to(referential, item)
lambda do |referential, item|
some_path(referential, item)
end
|
|
This tells the markup assembler whether or not this column should be
wrapped in a link (`<a>`). It intends to serve the same purpose as
`TableBuilderHelper#column_is_linkable`, but at the column level. The
idea is to remove that method when these links only operate by column
and not by pre-defined values like before/now.
|
|
This parameter will be used as the `href` to link the column value
somewhere.
We give it a lambda because this makes it easier to call any method on
the row object.
This means the accessor needs to take the object as an argument, like in
the `#value` method, because we don't have a better way to handle that
(it can't be done at initialisation time because at that point we don't
have row objects, we have a collection).
|
|
|
|
Instead of getting the referential to use when building the polymorphic
URL from the `UserContext`, pass in a referential directly.
The old code that used `user_context.context[:referential]` relied on
the fact that `ApplicationController#pundit_user` was defined as
follows:
def pundit_user
UserContext.new(current_user, referential: self.try(:current_referential))
end
(We pass `pundit_user` into `CustomLinks` from
`TableBuilderHelper#build_links`.)
However, Robert's change 747d333ffbcc8ee0c9f1daf93ccca32799434e04
removes the `current_referential` call from `#pundit_user`. In
`CustomLinks`, we actually always want to be using
`current_referential`.
For example, on `Companies#index` (/line_referentials/:id/companies),
`CustomLinks` fails to build a correct #show link because
`user_context.context[:referential]` is `nil`, when it should instead be
a `LineReferential` object, that gets returned by the
`#current_referential` helper method. Sure, `#current_referential` is
hard to understand, so maybe we'll change that around in the future, but
this at least allows us to use the current referential in `CustomLinks`.
Refs #3479
|
|
Had a problem on the TimeTables#index page where the #show and #edit
links in the gear menu would link to `/referentials/:id` instead of
`/referentials/:id/time_tables/:id`.
This turned out to be caused by a syntax bug in the condition that adds
the `Chouette::TimeTable` object to the polymorphic URL array. Now the
proper URL is rendered.
Refs #3479
|
|
|
|
Turns out the only reason why this code worked before was because the
only place I was using `table_builder_2` was for a list of
`Referential`s, and there's an explicit check for
`item.is_a?(Referential)` that avoids calling `current_referential`.
Otherwise, when that `unless` condition passes, we get a failure because
`current_referential` can't be found. It can't be found because helper
methods are not accessible in this scope (duh).
In order to make the referential accessible to the method, require one
as an argument. Now we explicitly pass the `current_referential` from
places where `#polymorphic_url_parts` is called.
Refs #3479
|
|
- All permissions tied to `!archived?`
- Tests adapted
- Policies refactored
? Is `create?` permission bound to `organisation_match?`
|
|
models and actions
- ApplicationPolicy nondestructive permission depend on model existance
- ApplicationPolicy destructive permission default to `false`
- Tied Policy permissions at ApplicationPolicy Level: edit? → update?, new? → create?, index? → show?
- ApplicationPolicy convenience methods `delete?` & `authorizes_action?(action)`
- Refactoring of `spec/helpers/table_builder_helper_spec.rb` accordingly
- Stubbing scope in specs (cannot switch to referential with a `build_stubbed` instance)
|
|
to moving authoriation BL into policies
|
|
|
|
newapplication helper default authorization, (no if) ->
* DefaultPolicy (all true)
* Add some policies (LinePolicy)
* Use `boiv:read` pour show, index
* Adapted `table_builder`
|
|
Add a few doc comments to the table builder to provide a little more
detailed explanation of the code.
TableBuilderHelper::URL:
* Describe dependency on `current_referential`
TableBuilderHelper:
* Add doc comments to the `collection` and `columns` arguments
* Add a description of the module
* Detail external global variable dependencies
* Provide an example, stolen from one of the tests
Refs #3479
|
|
We were using both the instance variable and the accessor on the same
line. Pick one and be consistent.
Refs #3479
|
|
The only difference between :name and :content was that :name contained
a string and :content contained HTML. But they're really the same thing.
Thus it makes much more sense to combine those into a single property
that means both, and handles content regardless of type.
Refs #3479
|
|
We need the ability to say that an entire table is not sortable. By
default, all tables are sortable, and individual columns can have
sorting deactivated. This blanket deactivates sorting for all columns.
Take our `sortable` argument and pass it to `#thead`. Then
`#build_column_header` takes that value into account when creating a
header column value.
The actual label used in the column header is determined by the old
`#column_header_label` method. We've now moved it into the
`TableBuilderHelper::Column` class because it makes more sense there.
The method will now return the column's `:name` property if it was
defined, and otherwise gets the translation for `:key` as before.
Add a test on `TableBuilderHelper` that verifies that a table with
`sortable: false` returns the correct HTML without sorting links.
Refs #3479
|
|
Don't set links as `method: :get` by default. This shows up as:
link_to _, _, method: :get
If we set the method to `nil` instead, we don't get a
`data-method="get"` attribute in our HTML output. Instead, we get no
`data-method` attribute, which is a lot better and cleaner.
I had originally used `:get` as a default because I wanted to generalise
links and certain ones we create need `:delete` or `:put` methods. I
figured, since we're always going to be passing `method:` to `link_to`,
we should have a sane default for that option. However, using `nil` is
even better as a default because then we don't get an extra attribute in
our HTML at all.
Refs #3479
|
|
Add comments that describe what each `or` condition is doing. At first I
thought maybe I should create separate methods to name these conditions,
but settled for comments instead.
Moved the final check to a method because that one seemed the most
obscure about what it does.
Refs #3479
|
|
Now that we have other classes that belong to `TableBuilderHelper`
(`URL` and `CustomLinks`), it makes more sense for this one to live in
its own file.
Refs #3479
|
|
In `#actions_after_policy_check`, we weren't correctly including actions
that weren't handled by the prior policy checks. Thus actions that
weren't [:delete, :edit, :archive, :unarchive] wouldn't get included in
the resulting list of actions.
Fix my logic error.
Refs #3479
|
|
Move `#action_links`, `#action_link_method`, and
`#actions_after_policy_check` to a new class. They all depend on an
action and/or a model object, so it made sense to group these together.
Also, these should really be tested, and moved out of a private method
context. They now live in `TableBuilderHelper::CustomLinks`.
The advantage is that we now have these methods grouped together in a
separate module that can be tested separately.
Needed to change some things around now that they're in a class:
* `obj` and `action` are now instance variables
* In order to call Pundit's `policy` method, we have to call it directly
on `Pundit`, since we're no longer in the context of a
helper/controller/view.
* Create a `UserContext` that can be passed to Pundit based on the one
created in `ApplicationController`.
* Rename some methods to make more sense in this new context.
* Move `actions_to_http_methods` to a class constant, so we're not
redefining it in every call to `method_for_action`.
* Use `I18n.t` instead of `t` alone, otherwise getting the translation
doesn't work.
* Move `TableBuilderHelper#polymorphic_url_parts` to a new class
`TableBuilderHelper::URL`. This enables us to use it in both
`CustomLinks` and the `TableBuilderHelper`. We can't use it from
`CustomLinks` if it's a public method in `TableBuilderHelper`, and we
can't use it in `TableBuilderHelper#tbody` if it's a class method in
`TableBuilderHelper`.
There's a problem with the action symbols that aren't directly handled
in `actions_after_policy_check`. The `:show` action was passed by the
workbenches/show.html.slim template, but it doesn't appear in the
resulting output even though it should.
Refs #3479
|
