We have a discrepancy in our development and production content servers (11g) in the
way that expired content is automatically handled.
- In dev, the original file is deleted and replaced with a file of the same
name, except with a "~1" appended to the end of the web location. The original
file is no longer available from it's original web location.
- In production, the same process occurs, but the original file is still
accessible via the original web location, which indicates it was not deleted.
It's been a struggle to track down the source of this configuration. Is this an
out-of-the-box feature, or does this have to be configured on it's own?
Yes, this functionality is the out-of-the-box feature.
By default each content item's revision has meta-field 'Expiration Date' which defines when expiration will occur.
Expired content revisions are marked correspondingly in the database (revisions.dstatus='EXPIRED') thus they will not be accessible in application via search, but can still be found by administrator (Content Management -> Expired Content).
Expired revision files are not deleted from weblayout, but renamed instead as not latest revisions - marked with ~{number} postfix.
Expired revision files are neither deleted from vault nor renamed.
Lets say we have 2 revisions (dID=31026 and dID=31025) of a picture 009139 (dDocName=009139). Both revisions are expired. In this case:
both revisions are marked as expired in DB:
DID DDOCNAME DSTATUS
---------------------- ------------------------------ --------------------
31026 UP_009139 EXPIRED
31025 UP_009139 EXPIRED
both revision files will be renamed in weblayout:
\ucm\weblayout\groups\public\#test\documents\multimedia\up_009139~1.gif
\ucm\weblayout\groups\public\#test\documents\multimedia\up_009139~2.jpg
neither revision 1 nor revision 2 will be renamed/deleted in vault:
\ucm\vault\multimedia\#test\31025.gif
\ucm\vault\multimedia\#test\31026.jpg
Regarding your issue with prod - make sure you had no further revisions after the expired one (in this case this revision will be, of course, available)
Related
we have an OBIEE 12.2.1.3.0 server in Linux that currently only has this OBI bundle patch applied:
29112070;OBI BUNDLE PATCH 12.2.1.3.190416
Since then, there have been 6 more bundle patches that have been released. I was wondering if each one has to be installed in the order they were released as they are considered cumulative, however on Oracles support site they show that they are all superseded by the latest, because well, they are all older than the latest bundle patch.
The latest patch is #32294042, and I was wondering if just that could be installed as it has these patches listed in the 'Bugs Fixed By This Patch" section:
OBI Bundle Patch 12.2.1.3.201216
24566569: DRILL-DOWN ERROR: SPECIFIED DRILL-DOWN SELECTION DOES NOT EXIST
27124002: PROCESSES USING BISERVER SSL STACK HANG AT 100% CPU WAITING FOR CLIENT DATA
31448057: Fix for Bug 31448057
30023519: Fix for Bug 30023519
26631503: EMAIL BODY IS RENDERING IN ONE LINE, WHEN SETTING EMAIL AS DESTINATION
31583579: Fix for Bug 31583579
30909437: Fix for Bug 30909437
31752569: Fix for Bug 31752569
31055308: Fix for Bug 31055308
31689614: Fix for Bug 31689614
31752589: Fix for Bug 31752589
31974393: Fix for Bug 31974393
31752601: Fix for Bug 31752601
30501937: Fix for Bug 30501937
31316014: "FILE SYSTEM ERROR WITH OBJECT: /SYSTEM/MKTGJOB/JOB52330" ERROR UPON JOB EXECUT
32283083: QA[REG]-ADMIN USER NOT ABLE TO DELETE CUSTOM FONTS UPLOADED
OBI Bundle Patch 12.2.1.3.201020
29899754: REL13: CHROME: QA:COULD NOT REANME AGENTS IN CATALOG IN CHROME BROWSER
30029029: CVE-2020-14766
31312661: CVE-2020-14815
27733354: REPORT JOB HISTORY DATE FIELD DROPDOWN HAS YEAR 3000 AS DEFAULT.
27641918: NULL VALUES IN TABLE CAUSE ERROR TO PDF OUTPUT
27800712: INCOMPATIBLE SORT ORDER ISSUE WITH UNION REPORT IF SET NULL_VALUES_SORT_FIRST=ON
28047277: OBIEE12C: NON-ADMIN USER GETS "YOU DO NOT HAVE ACCESS PRIVILEGE FOR THIS SA"
31360445: CVE-2020-11022
31448181: CVE-2020-14842
30690685: CVE-2020-14780
28535009: CHART PROPERTY TREAT NULLS AS ZERO FALSE IS NOT WORKING FOR LINE CHART
31712733: TRACKING BUG TO INCLUDE BUG 30690685 FOR BIMAD
31637106: CVE-2020-14864
30865195: CVE-2020-14784
31448244: CVE-2020-14843
28996803: BISERVER_MAIN_WINDOWS LABEL BUILD FAILURE
31087358: CVE-2019-11358
31747467: CVE-2020-14879
31752545: CVE-2020-14880
31858931: 12214[REG][-BIMAD-MOBILE APP CREATION FAILING IN LATEST OCTIBER BUNDLE PATCH
30763883: Fix for Bug 30763883
30763870: CVE-2019-1547
OBI Bundle Patch 12.2.1.3.200714
31024106: CVE-2020-14609
26556686: SFTP TEST CONNECTION FAILS FOR PRIVATE KEY AUTHENTICATION
27658023: R13 UNABLE TO FORMAT FILENAME WHILE SETTING UP REPORT JOB - UCM/SFTP DESTINATION
27137133: BIP REPORT REQUEST FAILS FOR THE FIRST TIME VIA /ANALYTICS THROUGH LOAD BALANCER
27539559: ERROR - STRING INDEX OUT OF RANGE : -31 WHEN REPORT IS CREATED WITH SUBJECT AREA
27501735: 12C SYSDATE STILL BEING SHOWN AS {$SYSDATE()$} IN JOB HISTORY
27545920: GUEST REPORT ACCESS ERROR
30971776: CREATE AGENT => ANALYTICS HANG & ERROR : [LDAP: ERROR CODE 11 - ADMINISTRATIVE LIMIT EXCEEDED]" AFTER 12.2.1.4.200114 + DIAGNOSTIC PATCH FROM BUG 30903799
30865185: CVE-2020-14585
30865177: CVE-2020-14584
30690694: CVE-2020-14571
31418768: CVE-2020-14696
29631418: CVE-2020-14548
29873706: CVE-2019-14862
29820321: BEFORE REPORT TRIGGER EXECUTES AFTER BURSTING SQL
28885154: BI PUBLISHER REMOVES RANDOM SPACES FROM RTF LAYOUT AFTER UPLOAD
26492182: PRIVATE KEY AUTHENTICATION WORKING ON ONE POD AND NOT ON 3 OTHERS FOR SAME CUST.
30690687: CVE-2020-14570
31405776: FIX 26556686 - SFTP PRIVATEKEY ISSUES - 12.2.1.3.200714
30579384: OBIEE 12.2.1.4: EXPORT TO EXCEL AND PDF PROPERTIES ARE NOT WORKING AS EXPECTED
27035568: 17.4.5-1164 : REPORT WITH LAYOUT TEMPLATE GETS CORRUPTED WHEN JUST OPEN AND SAVE
25896614: PDF FILES NOT WORKING AS TEMPLATES WHEN SAVED AS ADOBE ACROBAT DC 11 PRO FILES
27693385: INSECURE STRUTS 1.3 JARS STILL BE SHIPPED BY BITHIRDPARTY
31212299: Fix for Bug 31212299
31374057: CVE-2020-14690
31358667: CVE-2020-14626
OBI Bundle Patch 12.2.1.3.200414
22119433: BISERVER_MAIN:CRASH IN NQSSERVER
26832490: AFTER APPLYING PATCH 23299204 OK BUTTON DISABLED IN PARENT-CHILD HIERARCHY
30693647: 2.5 Authorization Bypass (Vertical Escalation)
25359947: MOUSE DISAPPEARS AFTER MOVING COLUMNS AROUND ON A DASHBOARD 6-10 TIMES
27960353: Fix for Bug 27960353
27365263: NEED TO ALLOW OBIS STARTUP TO CONTINUE EVEN THERE IS A CYCLE IN ROLE HIERARCHY
30961988: CVE-2020-2950
OBI Bundle Patch 12.2.1.3.200114
28747707: CVE-2020-2531
25826028: UNABLE TO QUERY RECIPIENT NAMES BY DISPLAY NAME ATTRIBUTE
27472788: OBIEE 12C: ROLES GRANTED ON "VIEW DELIVERS FULL UX" LOST AFTER RESTART
27443959: LINE IN GRAPH LINE IS NOT DISPLAYED IN IE11 IN HTML5 MODE
27345574: SAWLOG FILLS UP WITH: A TYPE MISMATCH OCCURRED WHILE EVALUATING AN EXPRESSION
26355617: CAN'T SELECT TABLE PROMPTS DROPDOWN LIST VALUE ON IE11
23211224: BICS PROMPT BASED ON TIMESTAMP DATATYPE COLUMN ERRORS WITH INVALID PROMPT VALUE
30374407: CVE-2020-2537
29879085: CVE-2016-1000031
27097220: HUGE NUMBER OF NOTIFICATION LOG ENTRIES FOR CONNECTION POOL EVENTS
27311972: IMPLEMENT RUNTIME EVALUATION OF DYNAMIC REPOSITORY VARIABLES
OBI Bundle Patch 12.2.1.3.191015
24415058: CVE-2015-7940
29780273: CBIL:11.13.19.01.0:CRM: REMOVE MESSAGE: COPY LINK REQUIRES ADOBE FLASH PLAYER
28709953: CVE-2019-2898
29506719: CVE-2019-1559
29953527: DISABLE ADOBE FLASH IMAGE SUPPORT IN ANSWERS
28627478: CVE-2019-2905
29488979: CVE-2019-1559
29506769: CVE-2019-1559
28722735: CVE-2019-2900
28831894: CVE-2019-2897
29827791: CVE-2016-7103
29750683: CVE-2020-2535
28565865: CVE-2019-3012
30380250: QA: CI BUG 30054026 IS NOT FIXED IN 9.191015
26382244: DISABLE FLASH TEMPLATE IN OAC
26551071: QA:UPLOAD TEMPLATE TEXT NEED TO BE MODIFIED AS FLASH TEMPLATE IS DISABLED
27440571: FLASH CONFIGURATION SHOULD BE REMOVED FROM OAC RUNTIME PROPERTIES
OBI Bundle Patch 12.2.1.3.190716
28900868: CVE-2019-2771
28886045: CVE-2019-2768
28885772: CVE-2019-2767
27839392: Fix for Bug 27839392
27580645: JNDI DATASOURCE ISSUE WITH PRE-PROCESS FUNCTION
29509993: CVE-2019-2906
27788081: CVE-2019-2742
OBI Bundle Patch 12.2.1.3.190416
25248099: NEED TO CHECK THE RETURN CODE OF BUILDROLEHIERARCHY
28797734: CVE-2019-2605
28885971: CVE-2019-2616
28722734: CVE-2019-2595
28627487: CVE-2019-2588
28747876: CVE-2019-2601
28077156: CVE-2015-9251
OBI Bundle Patch 12.2.1.3.181016
27747746: Fix for Bug 27747746
26560302: Fix for Bug 26560302
27826864: Fix for Bug 27826864
27826858: Fix for Bug 27826858
27826869: Fix for Bug 27826869
27747600: Fix for Bug 27747600
28143150: CVE-2018-8013
26957199: CVE-2017-5645
28095823: CVE-2018-3204
OBI Bundle Patch 12.2.1.3.180717
27019889: DYNAMIC REPOSITORY VARIABLES NOT WORKING IN 12.2.1.3.0
24623887: CVE-2017-10060
21216069: GRAPH CANNOT BE DISPLAYED IF DISPLAY VARIABLE IS SET
27155012: OBIS SESSION SWITCH DOES NOT CARRY OVER DEFAULT SUBJECT AREA
25071445: CRITICAL JOBS SHOULD NOT BE SHOWN WITH RED BACKGROUND ON JOB HISTORY PAGE
25484519: MAINTENANCE FLAG NEEDS TO BE CHECKED WHEN BIEE CONNETION FAILS
21309457: SSBEN ACCESSIBILITY: BIP REGION HAVING FORM AND STRUCTURE INSPECTOR ISSUE
26798068: HCMANALYTICS DEPLOYMENT ON 12CIWS FAILED WITH UNRESOLVED APPLICATION LIBRARY REF
27529288: 12C SMC PILLAR ESS APPS DEPLOYMENT UNKNOWNHOSTEXCEPTION: SLC01HJK.US.ORACLE.COM
26909225: CVE-2018-2925
27679984: CVE-2018-2958
OBI Bundle Patch 12.2.1.3.180116
24691274: CONFIG.XML FOR BI-ADF BROKER JDEV EXTENSION HAS AN ILLEGAL SPECIFICATION-VERSION
26266824: OBIEE 12.2.1.2.0 AN HTTP OPERATION TO XXXX.EMEA.XXX.LOC:80 TIMED OUT AFTER 1SEC
26486161: PS: PDFDOCMERGERV2/PDFMERGER ERRORS AND FAILS TO MERGE SOME PDF-CREATED BY LATEX
26171147: CALENDAR IS NOT UPDATED IN SEEDED REPORTS
26760055: PSR:PERF:BICS CLUSTER CONTROLLER SHOULD WAIT/ LOG/ RETRY BEFORE TAKING OBIS OFFL
26578260: SESSIONS IN OBIEE12C DO NOT FAIL-OVER GRACEFULLY WHEN ONE NODE IS KILLED
26975548: ADMINTOOL COMPARE NOT PULLING IN ALL DIFFERENCES IN RPDS
21766173: CVE-2016-3473
21766306: CVE-2016-0470
26535378: EL 12 UPGRADE A? LINKED ANALYSES NOT WORKING FROM HUMAN RESOURCES DASHBOARD
26944921: EEAR-TEST:CANCEL QUERY DOES NOT WORK
26017396: OBIEE 12C: CUSTOM SKIN / STYLE SET IN RPD VARIABLES IS NOT APPLIED TO DASHBOARDS
26541044: CVE-2018-2715
26775946: INCREASE THE DEFAULT VALUE OF OBIS_MAX_PERIODICTASKS_EXECUTOR_THREADS
25061256: CVE-2017-10068
26553225: CVE-2017-5662
26787841: Fix for Bug 26787841
26923935: 12C DEPLOYMENT - BIADMINESSBASERULEGENERATOR LIBRARY MISSING
26787682: Fix for Bug 26787682
26612444: HIDDEN DASHBOARD PAGE IS ADVERSELY AFFECTING DASHBOARD NAVIGATION.
27214490: SEVERE: EMBEDDED EXPORT SPECIFICATION JAR:BIADMINESSBASERULEGENERATOR.JAR
26632162: Fix for Bug 26632162
Bundle Patches are always cumulative. You can install the last one.
Generally you should try to stay up-to-date. it's not just application bugs which are fixed but also security bugs. The closer you stay to the current patch level the more secure you are.
I splitted the database, and then did some changes directly into backend. and then i tried to open front end, it failed to open and just asking for new/other files to open. what am i missing here ?
I gave up and opened my another backup access file and splitted it in frontend-backend. let say frontend name :DBstore7_fe and backend name:Dbstore7_be. link is ok and i can update data from front end. but i have to keep my old version of backend(Dbstore6_be) in the same folder. if i remove this old backend version, my frontend fails to open.
i tried another thing, i imported back all the tables to the front end, i.e - no more backend/linking. but still it is looking for Dbstore6_be. if this one there ....my database loads otherwise prompting for blank version.
You must run the "External Data", "Manage Linked Tables" wizard whenever you move or modify the backend file.
I have written a Firefox Extension using Web Extension APIs. It has passed the Preliminary review but the reviewer said that he cannot proceed with the full review cause when he installs it, he gets the following error -
"Unable to parse JSON data for extension storage"
Upon inspecting for quite sometime, I figured that Firefox creates a file called "storage.js" in the profile folder for each extension where it writes and reads from, all the local storage data for that particular extension. And if the extension tries to write to this file before this file is created, the error "Unable to write JSON data to extension storage" is thrown and if the extension code tries to read from this file before this file is created, the error "Unable to parse JSON data for extension storage" is thrown.
Now, my concern is how do I know for sure that the file has been created and that it can be written to or read from?
PS : This happens when the extension is just installed. For consequent sessions, this error wont come as that file is no longer missing.
This seems to be a bug in the current Firefox implementation, and your assessment is spot on:
The underlying ExtStorage module will always call read before get, set etc. even write and clear.
read will unconditionally try to access the underlying, extension specific storage file, that may not exist yet for freshly installed add-ons using the storage API for the first time.
This will therefore result in the logging of one such Unable to parse JSON data for extension storage message, no matter what you do with the storage API.
Therefore triggering the message cannot be avoided.
I suggest you do the following:
Contact the editors team, requesting they re-evaluate your add-on based on:
The message in question is really only a warning (when appearing after first access of the storage API by your addon).
Even when the message would be an actual error (the storage is corrupt), it would still not be your error, as the storage API implementation by mozilla needs to be more resilient then and there is nothing you can do anyway.
The message being issued on first regular use of the storage API, unrelated to what WebExtensions add-on uses that API and in what way, is a mozilla bug, and not something you caused or can fix yourself or at least work around.
Therefore denying a full review just because a mozilla bug erroneously logs a spurious message once without any other severe effects is... questionable.
File a bug about this so mozilla developers can address this issue. You'll wanna CC at least Bill McCloskey (:billm) since he wrote that code ;)
I decided to try out Firebase hosting and wanted to start fresh so I deleted my one and only app, but when I tried to create a new app with the same name I was unable to due to the error:
"This Firebase URL is not available"
I can only guess this is because of caching of app names/URLs? Hopefully it will become available (unless someone else beats me to it) after some timeout? Any info from others who have experience with this issue or otherwise know the answer is appreciated!
Not sure whether this is the right place to ask although Firebase suggest coming to SO because they apparently monitor Firebase-related questions closely according to their website.
Thanks!
Once you delete a Firebase URL, it is permanently unavailable. It cannot be recovered.
During confirmation, you should see a message like this, which explains in detail:
This stems from a number of abuse vectors that are possible by misappropriating a project id that the prior owner believes is deleted and could still have apps/releases in the wild attached to the defunct backend. Since compliance requires that we purge all data related to the project, including information about ownership, there's not even a way to restore one you personally deleted.
Magento 1.6.1
I have set up Authorize.net (AIM) for the client's store. Previously they were using saved CC method and entering information manually in Authorize.net's merchant terminal.
Most of it is working as expected, however for transactions that are flagged as 'Suspected Fraud' by Authorize.net, if the client does not update the transaction manually before the authorization expires, using 'Get Payment Update' in Magento fails because the transaction is expired (I believe it's five days for an authorize only transaction).
For the client, it seems the only way to update this order in Magento is to simply delete the order, as it doesn't appear the Paygate model knows about expired transactions. Performing 'Get Payment Update' simply returns 'There is no update for this payment'.
I have already modified the file: /app/code/core/Mage/Paygate/Model/Authorize.net to have the correct API URL as described in issue #27117 ( http://www.magentocommerce.com/bug-tracking/issue?issue=12991 - must be logged in to view ). This resolved the button not working for all other orders; however this does not fix the issue I am describing.
Is anyone familiar with Authorize.net's AIM API so that we can update these orders in Magento to something that makes sense (canceled, etc.) without having to delete the order? I am thinking it should be a case of adding a new order status to Magento, checking the update for an 'Expired' status, and setting the order to the newly created order status.
-- edit --
I just ran a diff for the file mentioned above and noticed that Magento 1.7.0.2 includes the _isTransactionExpired() method which seems like it would be the fix. Can it be as simple as updating this model with the newer version?
In this case, I manually included the _isTransactionExpired() method described in my question to the app/code/core/Mage/Paygate/Model/Authorize.php, and things appeared normal and it was seeming to work as expected.
It's now been a month and a half, and I've not had the client come back to tell me things are not working, so I am assuming this fixed the issue.