🇳🇱Netherlands @johnv

I tried to move the 'show_empty' into $items->isEmpty(), but the formatter settings are lost in the ItemList.
I does not seem right to override the layout_builder code, even if it core.
Also, it seems as I have a higher Drupal version then you, since in my 10.2.x system, #3119786: Default values are not displayed for image fields placed in Layout Builder → is committed, removing the line you mention.
Perhaps the problem is solved in a higher Drupal version?

Above patch changes the check for correct filling of the time, sepecifically the empty hours field.

Can you share the per-workflow WorkflowAccess permissions page?

Let's close this, assuming current code is up-to date for the requested functionality.

Please find the remainder of your original patch, for the hide and once features.

I added the 'data-drupal-selector' to the code in 📌 Use not-randomized drupal-data-selector, not #id Fixed and I credited you for that.

I added the 'data-drupal-selector' to the code in 📌 Use not-randomized drupal-data-selector, not #id Fixed and I credited you for that.

johnv → created an issue. See original summary → .

This should not be possible. I guess all other settings are not used then, too. Please check that.
Please check if the correct ViewMode is used.
IN the code, you can see several references to layout_builder please grep them and test the behaviour.

Above is committed.
Only the deprecated references to FormElement are kept, since maintainer does not know impact on existing installations running

johnv → created an issue.

johnv → created an issue.

Thanks, I will commit the attached patch, which is equivalent to the above soution.
I think this is a minor error, not a major one, since no site is broken, and the given test case (empty pm hour) will give an error message 'The time is incomplete. A value must be selected for hour.' anyway.

@rfmarcelino, Thanks for your response.
Regarding the error 'Argument #1 ($element)', did you change anything in the settings for 'Manage form display' of the workflow?

Sorry, I cannot reproduce.
When does it happen?
- existing installation after upgrade?
- new installation?
- ..

I assume the provided patch is OK.
Also, a comment is placed on the 'Manage form display' page, hinting to the unexpected behaviour.
Until now, I did not make that page prevalent, since:
- is does not support 'required'
- needs backporting existing installations
- does not support the 'per formatter' settings.

Please test current dev version and report back if the error has gone in all situations.
I will try to create a new version soon.

Yex, I will this week.
I am waiting for response on 🐛 TypeError: WorkflowTransitionElement::copyFormValuesToTransition() (line 356) Needs review

Let's remove the Install Optional Config, since the system will do that automatically once al prerequisites are fulfilled.

Question: are you experiencing this in a new install, or after the upgrade to version 1.8?

Regarding MR #8.
Thanks for the contribution.
It seems it is not against latest version. Latest Dev Version is 1.8 + 4 patches.
In the first part (setting fieldnams/sid to NULL), that is already assured in latest commits.
In the second part, I see that some data is missed, when elements are hidden in the Workflow Settings.
Please check attached patch. Sorry for not having learned how MR's work.

Regarding comment #4:
Indeed, in /admin/config/workflow/workflow/TYPE, the states are redundant. This is since the elements of the Transition are made customizable. The one in 'Manage form display' should be hidden, and the settings should not be used. I will open a ticket for that.

(Note: There is another issue requesting to have such settings on field basis, not on Workflow basis.)

The steps in 'Steps to fix?' are not to be used IMO. The result will be that you only change the state., without scheduling or comments. For that, you can just use the widget on the node, setting it from TransitionForm to Select.

Ofcourse this happens on other themes than mine.
Are you able to complete the following test?
- go to /admin/structure/block 'Block layout'
- Choose a region, press [Place Block], choose 'Workflow Transition form', save
- Now go to /node/NUMBER in order to display a node.
- You should see a block with the Workflow Transition form.
Thanks.

I guess optional config should not be forced to be installed.
Hook updates are nor run at new install. System will find itself the available optional configs. I will test with some dummy dependency.

There is no patch provider for this against 1.8 version. Please use dev version.

Please test dev version, and check] 🐛 Warning : Undefined array key "to_sid" in WorkflowTransitionElement::copyFormValuesToTransition() line 356 when using Ajax button from other field Fixed . Is it the same problem?

Working on this. I think i found a Solution.
Problem was a test on isNew() Which is True after adding/removing the file.

Cleaning up the code now.

And your file field is attached to the entity/node itself, not to the workflow?

Thanks,
do you use select/radios in workflow difeinition, or action button/dropbutton?

Please check attached patch.

I now see 2 use cases:

First:
- have a node type with Workflow and File
- create a node, add a file, save the node. Erro occurs because the 'triggering element' is not the save button, but "field_file_0_upload_button". After saving again, node seems to be saved correctly.
- the error does not occur is no file is uploaded.

Second:
- have a node type with Workflow and IEF.
- Did not test, but may have the same test script and result.

Workbench? I hope you mean Workflow.
I just created a new release 1.8. Please try that.

johnv → created an issue.

And indeed, I still haven't managed to fix the filter for Anonymous user. See [##3438820]

@tunaman, Just to reassure me: you did download latest dev version and cleared all caches?

I have some questions about your patch.
- the patch is not against latest version, with for example part of 📌 Refactor the JavaScript for the widget to use the once library Needs work in it. That is not a problem however to evaluate your patch. But it does already introduce some more focussing.
- you have a problem in a specific paragraphs constellation. I presume you have no problem in a less complex layout? (there were some issues with paragraphs before)
- in the first 2 parts, I guess the addClass/removeClass is the part that truely fixes your problem?
- in the first 2 parts you change the UX: removing the cleared row and adding the 'Add' link of the previous row. I guess that is not part of your problem, but an additional feature? Indeed , current behaviour is more like 'clear', then 'remove'. But I feel removing the clicked-upon row is confusing.
- in the last 2 parts, why do you switch from 'id' to 'data-drupal-selector'? Is that best practice? If so, I can change it, but it gives no technical/functional improvement, does it?

Additionally, please check the introduction of once in #3449164-11: Refactor the JavaScript for the widget to use the once library → , if it will not break your use case.
I need some confirmation on the proposed change there.

Hmm, disabling the cache does not help refreshing for anonymous users. Perhaps filtering must move from _pre_render to _post_render.

A fix was committed in 🐛 Views filter 'current open/closed status' does not work Needs review . There is still a problem with caching for anonymous users. please disable the view's caching.

I guess issue ✨ Each day in individual Views Table Column Fixed solves the request in D8 version.

Thisis now working in D8 version, dev or upcoming 8.x-1.18

For some reason it is not in a comment, but the following is committed: https://git.drupalcode.org/project/office_hours/-/commit/6a35f717bcf5c3c...

I was just messing with the inclusion of the views hooks:
\Drupal::moduleHandler()->loadInclude('office_hours', 'inc', 'office_hours.views');

It should be fixed, now. Please confirm, and I will release a new version.

I am sorry,
testing on 10.2.x and I cannot manage to get the filter invoked upon each view refresh.
Need help from the community here.

you are welcome :-)

This is a newly introduced error in D9.3 .
The workflow module 8.x-1.7+dev already has solved this problem as per 🐛 RuntimeException: Adding non-existent permissions to a role is not allowed Fixed .

Reopening due to comments.
FTR, IMO issue 🐛 Views with Open/Closed status are not updated Needs review is now solved in dev-version.

I created 📌 Add test for WeekTableElement in a form (not a widget) Active , so this issue can be closed.

johnv → created an issue.

The caching time was calculated incorrectly. Please test dev version.

The past commit contains similar changes to js/office_hours_status_update.js.
Please check that file.

I went through all changes, and understood and copied all but one:
The following patch is still pending, since adding it breaks the following scenario (testing with dev-version):
- enable Exceptions in field settings, using the correct Widget.
- Push the 'Add exception' button. Then an element is rebuilt by a Ajax call. after that, the JS-links are broken.
- You may still add an exception and save the node.
- Now reopen the node, and see that without pressing 'Add exception', the exception's JS-links are fine, but broken after pressing the button.

Thanks for your work!

diff --git a/js/office_hours.js b/js/office_hours.js
index b25721f..07a596a 100644
--- a/js/office_hours.js
+++ b/js/office_hours.js
@@ -203,7 +203,7 @@
 
   Drupal.behaviors.office_hours = {
     attach: function doUpdateElement(context) {
-     $(document).ready(function prepareElements() {
+     $(once('office-hours', '.field--type-office-hours', context)).each(function prepareElements() {
         // Attach a function to each JS link and initialize if needed.
         // N.B.: using * wildcard, since initially, no suffix is added,
         // but after 'Add exception'button, a suffix is added to the ID.

When code is reviewed, there are comments about unnamed functions, so I will keep the function name in attach: function doUpdateElement(context) {

Thanks, I was aware that there was some technical debt/errors in the code.
I will need to process the patch bit by bit, to check what has changed, and learn from it.

Thanks for the report. Attached patch will be included in next version.

Thanks, I will take a look.
Following patch to correct the widget code, which is broken after isolating the Element :-(

@Mav_fly, no I don't,
I can test again. I have a test system with only Drupal, and the 2 standard caching modules (for authenticated and anonymous users - the latter gives me many headaches)

Do you have any other caching services in place, like Varnish or 'reverse proxy'?

Above patch #9 also needs the additional one-liner from #11

Thanks for the issue and the solution.
However, the attached solution will be committed. The relevant code is outdated, and can be removed.

Please try the attached fix.

You're welcome :-)

In order to make sure that this functionality won't be lost in the future, a test case is needed.
However, I am not sure how to do that.
Do you know how to create such a test case: create form, save data, check data?

You can now use the most recent dev-version.

Please try the newest dev-version.

Indeed, but please do not use it . I am in the middle of a development.

As a preliminary version, please drop the attached file in the src/Element directory.

Then :

  public function buildForm(array $form, FormStateInterface $form_state) {
    $form = [];

    $config = \Drupal::configFactory()->get('example. Settings');
    $field_settings = OfficeHoursItem::defaultStorageSettings();
    $widget_settings = OfficeHoursWeekWidget::defaultSettings();
    $office_hours = $config->get('office_hours') ?? [];

    $form['office_hours'] = [
      '#type' => 'office_hours_table',
      '#title' => $this->t('Office hours'),
      '#default_value' => $office_hours,

      '#field_settings' => $field_settings,
      '#widget_settings' => $widget_settings,
      '#field_type' => $week_season_id = 0,
    ];
  
  $form['actions'] = [
      '#type' => 'actions',
      'submit' => [
        '#type' => 'submit',
        '#value' => $this->t('Send'),
      ],
    ];

    return $form;
}

and:

  public function submitForm(array &$form, FormStateInterface $form_state) {
    $office_hours = $form_state->getValue(['office_hours']);
    $config = \Drupal::configFactory()->getEditable('example. Settings');
    $config->set('office_hours', $office_hours);
    $config->save();
  }

I have refactored the widget into an element. Now cleaning up code. Please bear with me.

Please check the other issue 🐛 Views with Open/Closed status are not updated Needs review . Your problem should be fixed in #3438820-12: Views with Open/Closed status are not updated →

Please test the new -dev version and report back.
The problem was that the Season~isInRange() function was not correct. Therefor, the time wat replaced by a date early in the process, corrupting the isOpen() status.

Hmm, it seems there is a problem with public function getNextDay(int $time), which receives a Unix timestamp, and calls $status = $item->getStatus($time), that expects a HHMM time.

Problem is that your approach uses 'FormElements', not 'FieldWidgets'.
The FormElements are the single time slots, united in the Weekly FieldWidget.

Perhaps it is possible to wrap the time slots in a complex Element, like 'checkboxes' is a wrapper around x 'checkbox' elements.

You may borrow code from OfficeHoursWeekWidget::formElement(), which does $elements[] = ['#type' => 'office_hours_slot', ...]
or from OfficeHoursCOmplextWeekWidget::formElement(), which calles simpler widgets.

@alexpott, please ignore the file in #43. It is too long. See newly attached file.

@alexpott, please see my response in #2987548-43: LogicException: The database connection is not serializable. → with a test case using only the office_hours contrib module, hitting an AJAX button.

@alexpott, please check attached patch for some test instructions.

Test by:
- Install with normal install profile.
- Enable locale module 'User interface translation' with +1 languages.
- Enable office_hours module and add field to a Content type.
- In Field settings, Allow both Exceptions and Seasons.
- Select widget type 'Office Hours (week) with exceptions and seasons'.
- Edit with non-English page, e.g., /nl/node/8/edit .
- Enable both Exceptions and Season in widget settings.
- Create/Edit node with non-English page, e.g., /nl/node/8/edit .
- Click 'Add Exception' button. (You may need to click twice.)
- Check if an empty exception is added, or error occurs.
Set breakpoint at OfficeHoursSeason~label() and OfficeHoursSeasonHeader~process().
@see https://www.drupal.org/project/office_hours/issues/3399054 🐛 Ajax error on [Add exception] button if "seasons" is activated Active

You can provoke the error by switching between the following return values in OfficeHoursSeason~label():
- return $this->t($this->name);
- return t($this->name);
- return $this->name;
The first one will generate the error.

(IMO in previous Drupal versions, bootstrap::t() and $this->t() return different classes. I might be mistaken, because in my current D10.2 dev version, both return TranslatableMarkup, only created with different parameters. I never understood why there was/is a difference. )

Please try the new -dev version, since there has been major rework on this part, after the release of 8.x-1.7.
I have no installed eca yet, myself.