LPS-131007 Not needed anymore #328

This reverts commit d132795.

…vigation

…e to saml's jsps are in portal-web while dispatch actions are inside modules.

…ots of CI resources

…ormal site

…tion in normal site

…ment in content page

…h fragment

… items

…rget

…e have a null check anyways.

This test needs to be run manually after tweaking the configuration.

…eTemplateEntry doesn't take into account the private pages

…e and latitude

…rent node

…tions

…uration and needs to be refactored

…ly applied to tomcat and tcserver. I don't think we have any real utf7 usages from the beginning, otherwise other appservers would break.

…ata Engine App Co-authored-by: Elivelton Rodrigues <elivelton.rodrigues@liferay.com> Co-authored-by: Milton Castro <milton.castro@liferay.com>

Co-authored-by: Aline D'Oleron <aline.cantarelli@liferay.com> Co-authored-by: Elivelton Rodrigues <elivelton.rodrigues@liferay.com>

…swallow problems if code real has

…odels

…yModel to generate the dlFileEntryModel

…iceEntryModel here as they did not be used before they are reassign

…ction

…function

…tion

…page to function

…gs to function

https://issues.liferay.com/browse/LPS-121366

https://issues.liferay.com/browse/LPS-128501

Internal usages have already been migrated to the non-AUI `ImageSelector.js` in the same directory.

As noted in this issue: microsoft/TypeScript#37888 And specifically in my comment: microsoft/TypeScript#37888 (comment) There is a problem in the TypeScript compiler involving indirect references to unique Symbol types defined in projects connected by via project references. In short, `frontend-js-state-web` uses private `Symbol` instances as an implementation detail, and these wind up in the type declaration files as, eg: declare const ATOM: unique symbol; So, when another project attempts to use a function like `Liferay.State.atom()` that returns an object of a type involving that symbol, TS may complain with: TS4023: Exported variable 'blah' has or is using name 'ATOM' from external module "path/to/State" but cannot be named. The exact conditions required to trigger this are subtle, because using `atom()` is working fine in places like the `frontend-js-react-web` tests. My theory is that those work fine because the uses are all internal, so TS doesn't need to emit any type information involving the symbol. But in the case of `item-selector-taglib`, which I am working on for the purposes of this LPS, I have to export the atom, and that's when the error pops up. Remove the `export` and there is no error. So the problem is that TS has to emit a `.d.ts` file and it can't, because it can't "see" the value of the symbol in the consuming module. We can make the error go away like I am here in this commit, switching from a symbol to a plain old string. These objects are read-only and cannot be manipulated directly, so this is going to be fine, although I did like the way the symbol keys were "invisible" from the outside.

- We had a mess with the types before this PR[0]. The `propTypes` say that `fileEntryId` is required and must be a string, but in the component we were using `0` (the number) to mean something special (no image), and `'-1'` (the string) to mean something else (upload in progress). - Likewise, we were firing events that included image data, but none of the listeners were actually doing anything with it (ie. `_showCaption()` and `_removeCaption()` in `blogs-web` don't take any parameters. - So, in this commit I make the types uniform: `fileEntryId` is typed as `string` and we always set a string. To make the special meaning of `'0'` obvious, I created a named constant for it (`STR_NULL_IMAGE_FILE_ENTRY_ID`), following the local pattern. Now, I could export that for use in `blogs-web`, and probably will, but for now I am just hard-coding `'0'` over there; will do that tomorrow. - Instead of having a `useState` that manages the `image` object, I replaced that with `useLiferayState`, replacing my earlier `State.write()` calls. This is good because it means we communicate just by setting the state, as opposed to setting the local state _and_ updating the global store. But we should note some architectural weirdness here: we are kind of abusing global state here to have these two projects communicating with one another; you can only have one blogs screen active at a time, and one image selector, which is to say, this works in a non-colliding way only because we happen to have a UI that doesn't show more than one thing at a time. - One way the weirdness manifests itself is that the state isn't "really" global. We pass in `fileEntryId` to the image selector, and we use `useEffect()` to write that into global storage on the first render. In reality, the responsibility for seeding the global store should happen higher up (maybe in the page.jsp), but that just highlights the weirdness of it all... we're rendering a single image selector in a way that depends on global state and only works because we effectively "guarantee" that it's a singleton. Removed killable events as part of this, as advocated here: liferay-frontend#970 (comment) Test plan: 1. In blogs, add a cover image via drag an drop. Delete it. Change it and select a new file. Try this over and over again in different orders with the JS console open and see no errors. 2. Verify that the "small image" selector that appears under configuration still works as before. 3. Create a commerce catalog and add a product to it. Add an image using the image selector there and see it work as before. [0]: liferay-frontend#970

As pointed out here, TS is smart enough to figure out the type without it all being spelled out: liferay-content-management#1748 (comment)

As explained here: liferay-content-management#1748 (comment) `blogs-web` has two `<liferay-item-selector:image-selector>` taglibs in its `edit_entry.jsp`. Only the one the cover image one has a caption; the "small image" under "Configuration" does not. So, when we were firing events with `Liferay.fire()` from _either_ selector, it would wind up hiding or showing the caption on the cover image. This is a bit of a smell anyway, because the image selector is supposed to be generic, but it was secretly coupled to `blogs-web` and was sending it a special event, and doing so in a non-specific way (ie. an event without an id, which meant that `blogs-web` couldn't distinguish between cover image changes and small image changes). The fix, then, is to go back to managing `image` state internally to the component, and only communicate with `blogs-web` for the case of the cover image (as identified by the `paramName` attribute). The bug is gone, although a bit of the smell remains (ie. the generic selector is still doing something secret/special for blogs). The alternative of making the secret "public" by adding an attribute to the taglib isn't much of an improvement, so we're going with this approach as it is minimal and it fixes the bug. It also means that this isn't an amazing showcase of `Liferay.State`, but it does at least show that you can use it to replace `Liferay.fire()`/`Liferay.on()`, and that you can adopt TS in an existing module even in the smallest of ways, if you want to. The state atom still contains the image info (`fileEntryId` and `src`), even though something smaller would have worked (eg. a boolean). It's still pretty small, and at least encodes some information that might be useful when debugging. Test plan: 1. Before this commit (and on `master`). See that adding or removing an image to the cover image selector or the small image selector causes the caption to appear disappear. 2. After this commit, see that adding/removing works; the caption only shows/hides in response to cover image changes. Small and cover images can be added/removed without affecting the other.

As requested here: liferay-content-management#1748 (review)

…using geolocation field, since latitude was replaced by lat and longitude was replaced by lng

… backports.

…nstance

…editor

…y page template in web content editor

… a first simple banner

…ount user

This reverts commit c2ecd3c.

…rd” and filter/sort does not work reliably with text-indexed properties. We will consider indexing as multifield/keyword in the future, when we rethink the entityModel API.

Co-authored-by: Nícolas Moura <nicolas_moura02@outlook.com>

…feray/learn/taglib/internal/web/cache/JSONObjectWebCacheItem.java

… it clickToChatChatProviderAccountIdParts if we did a lot of splits in this JSP

…rovider, do we need to call addHeader or check the response?

…ing system catalog when company is deleted

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LPS-131007 Not needed anymore #328

LPS-131007 Not needed anymore #328

Commits on Apr 22, 2021

Commits on Apr 23, 2021