Extending events widget and using addFields breaks max limit fields

[abea]

Having an addFields property in a module extending apos-events-widgets seems to break the limitByAll and limitByTag fields.

  label: 'Events',
  addFields: [
    {
      name: 'link',
      label: 'Link',
      type: 'singleton',
      widgetType: 'link'
    }
  ]
};

I'm getting some of the handy new warnings:

⚠️  widget type events, field name by:

showFields for the choice all includes limitByAll, a field that does not exist in the schema

⚠️  widget type events, field name by:

showFields for the choice tag includes limitByTag, a field that does not exist in the schema

Maybe worth double checking apos-blog?

[boutell]

I can't reproduce this in apostrophe-open-museum.

At no point did I see the behavior you're describing, nor does it make sense to me still as I look over the code. apostrophe-events-widgets has no addFields, and apostrophe-pieces-widgets plays the beforeConstruct game properly.

However, I encountered some weirdness in my attempt to reproduce the issue:

• That project extends apostrophe-events as "events" and sets the alias "events" for that module.
• This works, as far as that module goes - it can find apostrophe-events as a base class - but, apparently if apostrophe-events is not configured directly the other modules in that bundle do not become visible as possible base classes. 😭 This is probably why @stuartromanek punted and extended apostrophe-pieces-pages and apostrophe-pieces-widgets instead.
• So I tried configuring apostrophe-events, which allowed me to extend apostrophe-events-pages and apostrophe-events-widgets. But, apostrophe-events is camping on the "events" alias so I get a conflict with the project-level "events" module and a hard fail when I try to have both. 👺That's against the rules. npm modules are never supposed to hardcode an alias. But if I try to fix it now it'll break somebody's project. 👺👺
• Still, I don't actually want apostrophe-events to be instantiated and I don't want it to be in the admin bar, separate from "events." So I added "instantiate: false" to the config for apostrophe-events. This worked: I can do all the things, extending apostrophe-events-pages and apostrophe-events-widgets, and nothing appears to go wrong with addFields which Stuart was already using here.

I think the alias thing would not really matter in practice if we fixed it so you can extend modules in a bundle as long as you're at least extending the root module of the bundle. That would meet reasonable expectations. I opened #1833 to track it.

Still can't reproduce the original bug though, so I'm closing this ticket, but feel free to reopen with a link to a project / branch that duplicates it.

On Thu, Feb 28, 2019 at 3:45 PM Alex Bea notifications@github.com wrote:

Having an addFields property in a module extending apos-events seems to break the limitByAll and limitByTag fields.

label: 'Events',

addFields: [

{

  name: 'link',

  label: 'Link',

  type: 'singleton',

  widgetType: 'link'

}

]

};

I'm getting some of the handy new warnings:

⚠️ widget type events, field name by:

showFields for the choice all includes limitByAll, a field that does not exist in the schema

⚠️ widget type events, field name by:

showFields for the choice tag includes limitByTag, a field that does not exist in the schema

Maybe worth double checking apos-blog https://github.com/apostrophecms/apostrophe-blog/blob/master/lib/modules/apostrophe-blog-widgets/index.js ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apostrophecms/apostrophe-events/issues/38, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB9fdQsmWeE7ntqRQxasyOnHJk0GtJpks5vSD_agaJpZM4bXsxu .

--

Thomas Boutell, Chief Software Architect P'unk Avenue | (215) 755-1330 | punkave.com

[boutell]

Well I won't close it yet... please do link me up to a reproduction of the issue.